Re: [Json] I-JSON Topic #2: Top-Level

[Phillip Hallam-Baker <[e-mail]>]

For protocols, I find the most convenient approach to be that the
message type be a tag and the message data be the corresponding value.

So if I have a protocol 'Fred' the HTTP binding is going to look like this:

GET /.well-known/Fred/operation1
...

{ "operation1" : {
   "tag1" : "value1" ...
   }}

While it is possible to rely on the command value in the URI, this
makes authentication a lot harder as the URI part of a request is
likely to be 'damaged' by proxies and the like. So I much prefer that
the command be a part of the JSON payload.

This enables the use of message layer authentication. It also makes
schemes of the form 'take command from Alice and lob it over to Carol
along with the authorization from Bob'. It also removes the assumption
that HTTP is the only legitimate binding for Web Services.


I can see cases where it would be useful to have a scheme where the
binding allows for an array of Web Service messages per binding
message rather than just one.

When I look at what my applications actually use from HTTP, it is basically:

1) The URL part
2) The session authentication header I defined as an extension
3) The Content-Length header for framing
4) Possibly the Content-Type in the future

Everything else is just noise that is needed to get through proxies,
firewalls and other nonsense that will never ever add value because we
know the message type and the data is not static so it can't be
cached.


Rather than looking at HTTP/2 as the next platform for Web Services,
it seems to me that we could do rather better with no headers at all
rather than some whacky compression scheme.