Re: [dispatch] A WG for HTTP API Building Blocks

Lucas Pardue <> Wed, 15 July 2020 00:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B89323A099C for <>; Tue, 14 Jul 2020 17:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 880mwtT02pLK for <>; Tue, 14 Jul 2020 17:33:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 250C23A099A for <>; Tue, 14 Jul 2020 17:33:01 -0700 (PDT)
Received: by with SMTP id q15so2299135wmj.2 for <>; Tue, 14 Jul 2020 17:33:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/wUAVEktc2bD+L1ian2HxPkqTKFDYSe+NJTH7zP5Mx8=; b=Wjw6GsVrbbmlHgyCiPTGx06nmcaEi+rohYMEkcNVZDIAak+R6hA8mQSwFFQ3Q/W8be KKuAcHL3nxQd8szLtD9OosZFLxRbIvvQn1fy6s3tSeMsyb8D6Uw9HpMAflRLt7x5JyPa w4xv09yWzScZ1Gd4rRMQcy4mSnhQSvd0zwQPfK7i9i1zwG57G/CfRPmO/+DVyTzheoJx Zp6lMTOpBCivgvZbLKTgNFpEkFXx3mE3IcxzATqMF5ppJF4gqecYMHTnNxWIYq133hCc vLlWZu27tw8eIzlGBB+Vo60ffQqFss8sXGjVun8ERxgefPYXmP1tUtrAxQykQnY0NjfJ L69g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/wUAVEktc2bD+L1ian2HxPkqTKFDYSe+NJTH7zP5Mx8=; b=Ui/PDL2cdv0MHj1cuSH0XHh2JV+fF0mQ/5PIFILRlkqkbOACpZ9YECu+e9aEP7l9yT Fq+fgh4aC23+yWfj0wkxPzj1y1pfiLWbMrvQz6hjkLprDJ2R/kXr/xaDgvMCtVA7rDbc opgeuJbteOo8R2QJ+o3cda7WIkMcMPWyOWX3oDRjYl/tmpFZSBgcdAlBWz+jsLjH+4zf jZZpTttejnGZEfvqKc8wMd7GQ0eCzR8qIVTXiZC109OGAqs9vZW4TSJNg3iW6dbPFdg+ g0HKg1Mv9tq/VXpraXgZVE1RXADir3kYBO7xZzLTVLugUsxCYGLCJZq9al/ZWDYJfJpP r3KQ==
X-Gm-Message-State: AOAM532a4eW61hpkr4+h19yZuG99apBYE8NlI9IfSlN0UrIrbwaZ25lt EoWPjRkmxub5zKCd6ZvktvrXLCjA+fIuNexPfv1E5vwyP5A=
X-Google-Smtp-Source: ABdhPJzlN4Bm1SXu5g+TcgyrKxD4DEJC71tt1jF8B9IoSBdXK+OXrec4KvfRu0WSkvQbFSWHxj4JHnFB9tyDIvLInKk=
X-Received: by 2002:a1c:9914:: with SMTP id b20mr5841320wme.15.1594769801206; Tue, 14 Jul 2020 16:36:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Wed, 15 Jul 2020 00:36:31 +0100
Message-ID: <>
To: Mark Nottingham <>
Content-Type: multipart/alternative; boundary="0000000000007fe0dd05aa6f47e2"
Archived-At: <>
Subject: Re: [dispatch] A WG for HTTP API Building Blocks
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jul 2020 00:33:03 -0000

Hey Mark,

I think this is a good idea in general.

On Tue, Jul 14, 2020 at 2:36 AM Mark Nottingham <> wrote:

> This is the proposed charter:
> ~~~
> HTTP APIs Working Group (HTTPAPI)
> HTTP is often for not only Web browsing, but also machine-to-machine
> communication, often called 'HTTP APIs'. This Working Group will
> standardise HTTP protocol extensions for use in such cases, with a focus on
> building blocks for separate or combined use.
> Its output can include:
>         • Specifications for new HTTP header and/or trailer fields
>         • Specifications for new message body formats, or conventions for
> use in them (e.g., patterns of JSON objects)
>         • Proposals for new HTTP status codes, methods, or other generic
> extensions, to be considered by the HTTP Working Group
>         • Best practices and other documentation for HTTP API designers,
> consumers, implementers, operators, etc.
> Other items are out of scope. In particular, this WG will not take on work
> items for APIs for specific use cases, and it will not define new HTTP
> extension points, or new extensions that are likely to be used by Web
> browsers.

On a personal note, I struggle a bit to understand how some proposal "foo"
would be demarcated as HTTP vs HTTP API. That is probably case in point for
the need of a community that understands these things better than me.
I suspect my problem is that the interpretation of browsing is a little
open and the charter could benefit from being arbitrarily more explicit.
For instance, one pattern that is emerging is building Internet
applications around the Web Platform but otherwise not supporting the
notion of "general purpose web browsing", examples I have in mind are
Progressive Web Apps, applications built on top of Electron, or "TV apps"
in media clients. Therefore, the statement "[will not define] new
extensions that are likely to be used by Web browsers" seems to rule out
technologies and that seems a bit unfair.