Should Web Services be served by a different HTTP n+1?

Taking a look at the discussion here on HTTP 2.0, it seems to be very
focused on the needs of browsers and less responsive to the needs of Web
services.

Now it is pretty clear that port 80/443 is going to have to support both
sets of use cases and Web Services have to tolerate being molested by
intermediaries trying to address Web browser considerations. But other than
that, the two sets of use cases seem pretty disjoint to me. We have already
hived off Web Sockets as what is essentially a completely different
protocol, perhaps it would be better to do that with Web Services as well.

My Web Services have a need for some sort of framing and I would really
prefer to do it above the level of the protocol so that there is a standard
interface that things like firewalls can understand.

But I can't see a use for content types in Web Services, let alone header
compression and the things being considered for HTTP/2.0. The header frame
I need is just not that big, my ideal needs are:

Request:
* Method + URI
* Framing data (chunked / content length)
* Authentication data

Response
* Response code
* Framing data (chunked / content length)
* Do not cache flag
* Authentication data

I don't use any of the rest of the data and in fact I don't want to either.
I deliberately discard it in my applications because I don't want the core
of the code seeing data that has not been authenticated.

Metadata is really important where there is a possibility it might change.
But I don't give implementers the option of any other charset than UTF-8
and if there is a choice of syntax there will be different web service
endpoints for each one.


So as far as I am concerned, I would like there to be a HTTP/2.0 for Web
Services but it is probably one that is a lot, lot smaller than 1.1.
Something that looks more like CoAp/Core than the HTTP/2.0 proposals.


-- 
Website: http://hallambaker.com/