Subject: Types of Web Service

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 12:36:54 -0500

On Thu, Jan 24, 2013 at 11:25 AM, Julian Reschke <[email-masked]>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/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 20:03:45 +0100

On 2013-01-24 18:36, Phillip Hallam-Baker wrote:
> On Thu, Jan 24, 2013 at 11:25 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> 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.
>

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

> 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.
>
> that we have a mess that could do with some clarity. In particular I
> would like:
>

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 15:15:00 -0500

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

> 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

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