Types of Web Service

On Thu, Jan 24, 2013 at 11:25 AM, Julian Reschke <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 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
2) Don't do XML encoding

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

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/