HTTP Reliable Messaging
I have been studying Bill de Hora's HTTPLR Specification for Reliable Messaging using HTTP. All in all I think it's a great start to a somewhat complicated situation. It doesn't address issues like Once-and-only-Once delivery (as multiple clients could download the same message) or ordering of the messages. It does talk about reconciling the message deliveries between client and server, in both directions.
The specification makes good use of the HTTP verbs and HTTP status codes, which I love. If they're there, and they apply, use 'em!
I'm going to jump into my questions about the specification, so please bear with me. If you have the time, go ahead and read the specification.
I'm a little concerned about the use of DELETE when reconciling message upload (as specified in section 8.3).
The HTTP spec reads "The DELETE method requests that the origin server delete the resource identified by the Request-URI." To me, that says we're deleting the /resource/ and not the /uri/.
In section 8.3 of the HTTPLR spec, we are deleting the /resource/ of the /upload exchange/. OK, that makes sense because it signals that message upload is complete.
I have trouble here: We've PUT our message to the /upload exchange uri/. And the HTTP spec reads for PUT: " The PUT method requests that the enclosed entity be stored under the supplied Request-URI."
I read this as we've just asked for our message to be stored by the upload exchange uri. BUT... We then delete that upload exchange resource as the signal for message completion.
I have trouble with this because, semantically, I think we just deleted our message. I know we've deleted the upload exchange resource, but since we PUT our message to the upload exchange uri, our message gets deleted, too.
Am I missing some piece of HTTP semantics here?
I've attached a picture of a possible scenario below. Basically, the Upload Exchange URI does not receive the PUT of the message contents. The message contents are uploaded in the POST, where POST has the semantics of "append this message to your collection". The Location: header is used to return the Upload Exchange URI, which can be deleted later by the client to signify completion.
The specification makes good use of the HTTP verbs and HTTP status codes, which I love. If they're there, and they apply, use 'em!
I'm going to jump into my questions about the specification, so please bear with me. If you have the time, go ahead and read the specification.
I'm a little concerned about the use of DELETE when reconciling message upload (as specified in section 8.3).
The HTTP spec reads "The DELETE method requests that the origin server delete the resource identified by the Request-URI." To me, that says we're deleting the /resource/ and not the /uri/.
In section 8.3 of the HTTPLR spec, we are deleting the /resource/ of the /upload exchange/. OK, that makes sense because it signals that message upload is complete.
I have trouble here: We've PUT our message to the /upload exchange uri/. And the HTTP spec reads for PUT: " The PUT method requests that the enclosed entity be stored under the supplied Request-URI."
I read this as we've just asked for our message to be stored by the upload exchange uri. BUT... We then delete that upload exchange resource as the signal for message completion.
I have trouble with this because, semantically, I think we just deleted our message. I know we've deleted the upload exchange resource, but since we PUT our message to the upload exchange uri, our message gets deleted, too.
Am I missing some piece of HTTP semantics here?
I've attached a picture of a possible scenario below. Basically, the Upload Exchange URI does not receive the PUT of the message contents. The message contents are uploaded in the POST, where POST has the semantics of "append this message to your collection". The Location: header is used to return the Upload Exchange URI, which can be deleted later by the client to signify completion.