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

Roberto Polli <> Wed, 02 September 2020 10:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62B063A0E75 for <>; Wed, 2 Sep 2020 03:29: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 PTZP5l1YkC-p for <>; Wed, 2 Sep 2020 03:29:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03FC13A0E73 for <>; Wed, 2 Sep 2020 03:29:47 -0700 (PDT)
Received: by with SMTP id p13so4512136ils.3 for <>; Wed, 02 Sep 2020 03:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qthP7B2EybQkcmpj/vvBn0hCzSwENo5eEaJGbJCKK40=; b=bZyofC9FCB8RuqZxdmY2OqBCf2G7IfdbrCqcMew1dDV7P9GusIRihq74JTh6MOABD3 1ben+gjw3LlUn/pjzVfsT+L+0J6RiXW6kXnm+FWedtgL9o0cFgseoXUYMj/8NRg8t6YQ 1JHv3Sjw5eY8SrRUI6k/IpijhftfOe461a24hYtsN0ubKufZpg03dr1F6C2nGtAwyqxH sCy5PHYbYbTGCmDlIIxCaQTLlRSB1KB5wYvH5CrQLM3f7vM6EnPW7gddMZrYgoO3GPi+ y8YgfKI0SyphFAldMqCh5l3IUwKXsRMxpgI2ScMKVRf12DugqYcEp4yEWD47CEY/W01F Imqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qthP7B2EybQkcmpj/vvBn0hCzSwENo5eEaJGbJCKK40=; b=oxg8JbLOCPMulU2jppb60UgFFqt3xJ1ZPdz1Li9vZotBdTmzVaet9/Z0uBzeNdQT/h h8rHDZoVocOtJ9DnGJyqBAxDDCDIC+er9sF9WfA0ORiqlKx6PnUmtrxjtSQ18x7XgF/d 8JOMgzpZnzVlFGio3c3omqzIJGCNk+8PTYk5Bi3hBombe7DMhr+NdUqfsA4do1FLHz8g ALpas87Rw0IQ9XiZYUUNvZ6YUU2w0Nd1aI4cMZ9iBUZw+v99ttdykyRXYLUHUVCIZX1A yWBuXlwLGrcfKYGPd8+ERKha1p5IDS4cDWaRPu+0bi4d+Q1daU8zVn4vaAkW68g6cHdK ZAHg==
X-Gm-Message-State: AOAM532OuLO8dEQphexH795njtjY/7yevgn5cSiDMMf7ilzunRL7+1xc lbIYFVTAYIZkVUPfa8byNdxE5jQS7K7xKVIy7A9r7wE9r0P8Ew==
X-Google-Smtp-Source: ABdhPJyzUiUSeARZhRraAPhxE0y/Gg3Sq4U/uoTEMtTnoaeDYL3RwtTx1Kt0IFgRFfn/fHfzMB/4bU9Dg06+20EcsIk=
X-Received: by 2002:a05:6e02:110e:: with SMTP id u14mr3038767ilk.270.1599042585862; Wed, 02 Sep 2020 03:29:45 -0700 (PDT)
MIME-Version: 1.0
From: Roberto Polli <>
Date: Wed, 2 Sep 2020 12:29:34 +0200
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000004fa55d05ae521d3b"
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, 02 Sep 2020 10:29:50 -0000

Hi Mark et al,

I think that a WG for HTTP API Building Blocks is really necessary to avoid
fragmentation and is a great opportunity to provide a common ground for
providers and
consumers to meet.

Mark wrote:
> [http api wg] 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.

Darrel wrote:
> I do believe now is the right time for this effort.  The majority of
large companies have recognized the need for network based
> APIs to be an essential part of their technology platform.  I see this
regularly as part of my work with the OpenAPI Initiative.
> However, frustration with the inconsistent and sometimes poor use of HTTP
is causing companies to look closely at more prescriptive but less
ubiquitous solutions.

When dealing with large ecosystems of API providers - eg like in government
- with hundreds of suppliers
it is very hard to provide guidance even when you have RFC/BCP. In EU we
are even facing the challenge
of providing cross-border APIs for all Member States, and it would be great
to provide a global framework to support the principal choices :)
This can be thus relevant not only for consumers, but for providing
services to citizens.

Which are the next steps toward the creation of the WG?

Have a nice day,


[I just subscribed to dispatch, in case the mail is not properly threaded,
this is the original link]