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

Phillip Hallam-Baker <> Thu, 29 May 2014 17:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86BF31A048A for <>; Thu, 29 May 2014 10:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 98AkdH8Rloyl for <>; Thu, 29 May 2014 10:45:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31A871A0450 for <>; Thu, 29 May 2014 10:45:27 -0700 (PDT)
Received: by with SMTP id k48so799615wev.3 for <>; Thu, 29 May 2014 10:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kjqDLa/hGHRoejXakac88Od590nJEiH3F4o7rTi8RnE=; b=g1xrbQH3L0WdLHyf4TU0mKwYuyjJsZ6v8KRaJ7fRoDuGCJ8nHMDCbb5iv6tQzRmFmb Yz88POzdM/UKcuxs+cA0i9CxP9g+12qdgnHnFTSJxMfGqoCu3TNqG0iW7Lj3ptDmRfER UWw4qbOe0BaMr3wtSYJGqD2GYsMIR9/cTdmCo4wvvoKKBwUIXKXMC/daDLsrYTs6bJMY YiB+nCHRRs6tAvzZ0ZGav/j6hv77ETEgmdfDMTZFLFL/Lfc6X5cH2Fjoa5EDD5rUzVVN IT/QdhJCfVoxFbRHqgBwvwYPoIKJzV8DFY4H/7bNI5zKA9rRwthM+zcQw8B5S0a/PpPJ e07g==
MIME-Version: 1.0
X-Received: by with SMTP id f11mr39204959wik.59.1401385522195; Thu, 29 May 2014 10:45:22 -0700 (PDT)
Received: by with HTTP; Thu, 29 May 2014 10:45:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 29 May 2014 13:45:22 -0400
X-Google-Sender-Auth: H_cR_0NnmQYSCRHfyZIw8xMk7lU
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Nico Williams <>
Content-Type: text/plain; charset="UTF-8"
Cc: JSON WG <>, Matthew Morley <>, "Matt Miller, (mamille2)" <>
Subject: Re: [Json] I-JSON Topic #2: Top-Level
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 May 2014 17:45:29 -0000

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

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.