Supporting sending replies

[justinvdm]

This and #26 will make replying possible.

[justinvdm]

Ready for review.

[justinvdm]

Not sure if this is the right code to use. I think 404 responses are usually for telling the client that the requested entity was not found, not that something needed to fulfill the request was not found.

[rudigiesler]

So the action is "reply to this message" and we're saying "that message doesn't exist". So I would say it's a 400 Bad Request, but I think it would be good to have a discussion on this.

[rudigiesler]

Is there a reason why this is in stores, but not used in stores and used in channel?

[justinvdm]

+1 on 400.

Ya, wasn't too sure where to put the error. I put it in stores in case something else irrelevant to channel was using stores needed to raise such an error. Happy to move it into channel though.

Might be a sign that we need to raise an error in the stores methods (counter to what I suggested in an earlier PR review), but not too sure, still might seem weird to have some of our methods throwing errors and some returning None.

[rudigiesler]

It might also be a bit strange having the store raise a 400 error if it can't find something.

[justinvdm]

Looking at the spec, 400 looks appropriate:

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)

Rather than

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

Will go with 404 and move the error to channel for now.

[rudigiesler]

Just those two comments. Looking good to me otherwise.

[justinvdm]

Ready for re-review.

[rudigiesler]

👍