Re: Types of Web Service

On 2013-01-24 18:36, Phillip Hallam-Baker wrote:
> On Thu, Jan 24, 2013 at 11:25 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto:julian.reschke@gmx.de>> wrote:
>
>     That being said: can you clarify what you understand as "web
>     service", and how exactly it differs from a browser scenario? That
>     would be helpful to understand your concern.
>
>     BTW: I'm also not a big fan of introducing too much complexity into
>     the header representation; I think there's a consensus that that new
>     complexity needs to be justified by what we gain from it.
>
> One of the things this has uncovered is that most people here seem to
> have a rather different idea of a Web Service to me.
>
> According to the definition we started with back when SOAP was
> appearing, a Web Service was an any application protocol that ran over
> HTTP. According to that definition OCSP would probably be the first IETF
> Web Service.
>
> There are two very different types of Web Service though. OCSP is
> layered over HTTP so as to make use of HTTP caching. The protocol is
> intentionally idempotent and transactions do not cause state changes.
>
> OCSP is a machine-machine interaction but it is still essentially a
> request for content. The request format is highly structured but it is
> still an information retrieval protocol.
>
>
> The other type is the type I am more interested in these days where
> caching is not desired, either because the protocol causes state changes
> (is not idempotent) or because caching is simply not useful. The request

...it is not "safe"...

> and response messages both contain a data structure. It is not merely a
> machine-machine interaction, it is an inter-process communication.
> Process X on machine A sends a message to Process Y on machine B and
> waits for a response.
>
>
> The design of the SOAP stack is the way it is because it is essentially
> a wrapper that lets COM components talk to each other via an XML
> Serialization over a HTTP transport. It does other things but the need
> to have all those slots comes from the need to have a framing within the
> HTTP framing.
>
> WS-security and WS-* is the way it is because it is an attempt to secure
> SOAP using XML Signature. Which is a completely screwed up architecture
> because XML Signature requires canonicalization.
>
>
> 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.

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

> I do not like JSON signature more than I like XML Signature though. Both
> seem like a good idea but the hard part of a signature format is to
> specify the exact sequence of octets that is signed. So there has to be
> some form of framing. Using a format that can only specify text for
> framing binary data inevitably produces a lousy result.
>
> So I really don't like where we are with Web Services right now. I think
> that we have a mess that could do with some clarity. In particular I
> would like:
>
> 1) A simple scheme for encoding headers
> 2) A compact representation for the most commonly used header data
> 3) Eliminate unnecessary duplication of header data across transactions
> 4) Support expressing authentication data in message headers
> 5) Support arbitrary communication patterns efficiently
> 6) Allow for extensibility
>
> Lower priority
>
> 7) Support use of multiple TCP streams.
> 8) Support use of Multicast and TCP streams in combination.
>
> --
> Website: http://hallambaker.com/

Best regards, Julian

Received on Thursday, 24 January 2013 19:04:49 UTC