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

+1, many times over.


On Fri, Jan 11, 2013 at 12:18 PM, Tim Bray <tbray@textuality.com> wrote:

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