W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Types of Web Service

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 24 Jan 2013 15:15:00 -0500
Message-ID: <CAMm+Lwh07nVjD+J=Fjw=0BEJN=rd+aEL1LZW6Nx=XrhkPDH_AQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, Jan 24, 2013 at 2:03 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-01-24 18:36, Phillip Hallam-Baker wrote:
>> To understand REST, it is important to note that there are really two
>> definitions at this point:
>> 1) What Roy Fielding originally proposed
> ...described.
>  2) Don't do XML encoding
> Sorry? The choice of payload formats is entirely orthogonal to REST.

And inheritance had rather little to do with the original SIMULA/Smalltalk
definition of 'Object Oriented Programming'.

I didn't say it made any sense.

>  What Roy actually proposed results in a different approach to encoding
>> of idempotent transactions where caching is desirable. If the Web
>> Service is not idempotent then see case (2).
>> So the classes of Web interaction I see are
>> 1) User directed content retrieval
>> 2) Machine directed content retrieval
>> 3) Remote Procedure Call
>> 4) Inter process communication
>> HTTP/1.1 supports 1 through 3 but not 4 which is why we needed Web
>> Sockets to provide an escape hatch. The HTTP protocol is unidirectional
>> RPC.
>> One of the features I would like out of HTTP/2.0 is to support arbitrary
>> communication patterns so that it is possible for a party on either side
>> of the communication channel to initiate communications at any time.
>> That would make HTTP a true Presentation Layer.
>> When used as a serialization format, JSON has all the expressive power
>> of XML and ASN.1 but far less complexity. I therefore prefer JSON unless
> Actually, it doesn't, unless you add another stack of semantics on top of
> JSON. But that doesn't matter, as the protocol isn't and shouldn't be
> concerned with payload formats.
>  there is a legacy issue. I see no value in using form-uri-encoding
>> except in the specific case of uri-encoding of an idempotent, cacheable
>> GET request. My preference is to use JSON in both directions.
> You can in HTTP/1.1 already.

That is what I do. when I am designing. I just wish we could get away from
the idea that REST means doing uri-encoding on the request rather than to
do with using a cacheable identifier.

If the Web Service is of type 2, that is a Machine directed request for
possibly cachable content, probably the approach that would make best sense
would be to use a message digest of the request after canonicalizing ...
hey we just reinvented Harvest (or Squid as it is now called).

Website: http://hallambaker.com/
Received on Thursday, 24 January 2013 20:15:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC