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

I disagree strenuously.  The semantics of HTTP as they are today map well
onto my RESTful-app-construction needs.  In particular: dispatching on
content-type, the use of standard caching stuff, also if-modified-since and
(especially) ETags.  -T


On Fri, Jan 11, 2013 at 12:05 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> 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/
>