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

Mary Barnes <> Tue, 14 July 2020 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A0523A0C55 for <>; Tue, 14 Jul 2020 10:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_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 oFFBsyXHyM3G for <>; Tue, 14 Jul 2020 10:41:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87F793A0C4D for <>; Tue, 14 Jul 2020 10:41:48 -0700 (PDT)
Received: by with SMTP id j20so7884958pfe.5 for <>; Tue, 14 Jul 2020 10:41:48 -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=8R6IlSEtZKzxtngd/B17o1G/PhL9CriG8M9nfVsrzsc=; b=I8SaP4p8rNb2YBwP77K2m6Ge/E9sNqb1uPqWdmn1l2zjpOVI/XJJEnJtwDSN682M2K o/PX/40vVzM7wbsA6pEbEz/C2kCkcR5LxRpnhnYOH+/SdmYRdBUNVajrYaAvJ5liGwxP ikOilsMJjTUCkEFYzo7h2SzA2ioXu8RI0IWY4KMGy4PepaawKma2Oz3r719BtVNSfqr7 e+c3Wyaz85AlHzFDW5OOCDH3rvE/qBiZHNVl6H/jRVTkX07fuTuzqMjYyiYVh0Exg/Ly Z/nC6/08NHaL/2Bta4A5S0b9tL1ZPNKKsa+jD6jgn0MPLNVT4WmtwuV0lCslvakVprqi Uyaw==
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=8R6IlSEtZKzxtngd/B17o1G/PhL9CriG8M9nfVsrzsc=; b=OpT2XipPZRUhv+SLCoAc04PFoDHzQ0ceJG2pndy54oBfOafiKSjzzv/U7dwiVaCmpa 6t5Kc0KSOLzhsFHeA8l5iU4Tf33u52AAs4DK8jVcf/hz95+BLNmjKWbfAQF6h9S1tYCn gGmBsClaLnUQD/q6CSL8efgSWU77nY9GX+XJ99Y/+rYzOwVuI73pt/VEBK1R7qdFQe2h QgogTe+7XkkbZx8TZ1OXGVg4yPDeKoYExMEi/16H409K2ghYYC4tklg3j8NehYiQjcae wuDIlXXZA/jfloOOoNB1vuPsOSBGBYjdOwFkqr4X33FPVMHXF10Xnwmco2szdmJ+RgBG eLjA==
X-Gm-Message-State: AOAM530bIT8j3dw5z/hqpoj4wSDUlD+RY6elpEPHMdoIvCbw6v4XYmGS ZVEDqbLrpNhj517ZGs0IEVNvkTFbRzwiNbKEEM0OyQ==
X-Google-Smtp-Source: ABdhPJx9rUMrq/Z8INkQLQauF/YDSoz459oYA4cipnO0WeUmTwtVU3mwIuptOp7twiWf8/HLosm/3z8p+dzJCbEo4c0=
X-Received: by 2002:a62:be06:: with SMTP id l6mr5382144pff.310.1594748508054; Tue, 14 Jul 2020 10:41:48 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Mary Barnes <>
Date: Tue, 14 Jul 2020 12:41:36 -0500
Message-ID: <>
To: Mark Nottingham <>
Content-Type: multipart/alternative; boundary="00000000000054292305aa6a52d2"
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: Tue, 14 Jul 2020 17:41:50 -0000

I think it's a great idea and yes on [1] - the vast majority don't
understand REST.    And, not all HTTPS APIs that are called RESTful (or
even worse "REST API"s) actually follow the REST model - i.e., folks are
using it as a generic term for any API using HTTPS.


On Mon, Jul 13, 2020 at 8:36 PM Mark Nottingham <> wrote:

> I've been chatting with folks in the background for a while about starting
> a WG to take on specs to help folks building HTTP APIs.[1]
> HTTP has been used for machine-to-machine communication for most of its
> lifetime, there are a number of functions that are designed and implemented
> in an ad hoc fashion, or with several competing approaches. Establishing a
> WG to standardise some common functions might help, both by documenting
> some common building blocks, and serving as a locus for a new community --
> one that's related to but distinct from the HTTP WG.
> For example, these specifications were either AD-sponsored or on the
> Independent stream, but could have been in-scope for such a WG:
>  - rfc6570 URI Template
>  - rfc6892 The 'describes' Link Relation Type
>  - rfc6901 JSON Pointer
>  - rfc6902 JSON Patch
>  - rfc7807 Problem Details for HTTP APIs
>  - rfc8288 Web Linking
>  - rfc8594 The Sunset HTTP Header Field
>  - rfc8631 Link Relation Types for Web Services
> ... and there are also a number of current drafts that such a WG might
> consider, e.g.:
>  - draft-wilde-linkset
>  - draft-nottingham-link-hint
>  - draft-dalal-deprecation-header
>  - draft-polli-ratelimit-headers
> 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.
> New work items can be added after a Call for Adoption on the working group
> mailing list and consultation with the Area Director.
> To be successful, this Working Group will need to have active and broad
> representation from across the industry -- e.g., API gateway vendors (and
> other intermediaries), API consultants, API tool vendors, in-house API
> teams. Therefore, adopted proposals should have public support from
> multiple implementers and/or deployments before being sent to the IESG.
> This Working Group will need to coordinate closely with the HTTP Working
> Group.
> ~~~
> Because a large part of the task here is building a representative
> community, I think this group should be chartered without specific
> documents; it can deliberate on what's appropriate to start with once
> constituted. It should also be periodically evaluated to make sure that
> it's functioning well and representative of the greater community, with the
> assumption that if it isn't, it would be closed (I'd hope that ADs do that
> for every WG anyway, but since this is trying to establish a new venue, it
> should be considered on probation).
> The ADs have responded positively, and asked me to bring this to DISPATCH
> for wider review. I'm happy to talk about it in the meeting if there's time.
> Cheers,
> 1. a.k.a. "RESTful APIs", although that's a misunderstanding of what REST
> is.
> --
> Mark Nottingham
> _______________________________________________
> dispatch mailing list