Re: Types of Web Service

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/