There has been some discussion amongst the binding TF regarding
example bindings, to help us discover requirements for defining a
binding. As part of this, I generated a candiate for a HTTP binding
definition.
Find attached a thread regarding this; the first message is my reply
to some of Henrik's comments, and the second is another reply to the
same message, and finally the actual candidate.
Comments welcome.
--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Forwarded message 1
Thanks for the comments.
> * It is not clear whether you allow something like MIME
> multipart/related - or DIME encapsulations as well?
> * Just as a side note, HTTP doesn't really say anywhere but I would be
> very surprised if not all kind of implementation stuff will break if GET
> requests start to have a body.
IIRC I only documented using GET when there is no soap message to be
sent in the request, so there would be no body in that case.
> * There are situations where other status codes than 204 would be more
> appropriate given the situation and what HTTP dictates. An example is
> 202, or even 200. For example, it should be ok for a service to say that
> it accepts a event notification for example and just responds with a 200
> status code.
Are you saying that some applications will wish to use a 200 status
code with a 0-length body for a response? That seems to me that it's
sticking the application's semantics into the binding, which may or
may not be a good thing.
It could be listed as a service - i.e., "if you wish to send a
boolean acknowledgement over an HTTP response message without
incurring the overhead of a SOAP envelope, you can send a 200 status
code w/ 0-length body to signal success, and a 403 status code to
signal failure'.
A problem that I very quickly came up against, and which I hinted at
in my previous message, is that it's easy to go overboard with
services - at a not-so-distant point, you start listing all of the
features in the underlying protocol. HTTP is a very featureful
protocol - can we get a sense of the group as to how far the listing
of services should go?
Another thing that should probably be made clear is that
implementations must be able to act in full compliance with the
underlying protocol's specification; implement all of the required
features, etc. It's obvious, but I can very easily imagine someone
only implementing the parts referred to, and leaving out
"unimportant" bits (e.g., host header, redirects, etc.). This would
leave them unable to deal with the mechanisms that might get injected
into message streams by intermediaries, the underlying HTTP
implementation, etc.
I also wonder what implications that has for SOAP compliance... e.g.,
if we documented the 200/403 behaviour, would an implementation need
to expose it, at the SOAP level, to be considered compliant?
This, I think, is where we dance the line between defining a protocol
and defining an API...
> * Regarding fault, do you anticipate to use a specific fault code (like
> 500 for example) to indicate a fault? (I hope so :)
I would have thought you knew my position on that one by now ;)
--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)