Building Blocks for HTTP APIs (httpapi) Internet Drafts


      
 The Deprecation HTTP Header Field
 
 draft-ietf-httpapi-deprecation-header-03.txt
 Date: 11/12/2023
 Authors: Sanjay Dalal, Erik Wilde
 Working Group: Building Blocks for HTTP APIs (httpapi)
The Deprecation HTTP response header field is used to signal to consumers of a URI-identified resource that the resource will be or has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional information about planned or existing deprecation, and possibly ways in which clients can best manage deprecation.
 The Idempotency-Key HTTP Header Field
 
 draft-ietf-httpapi-idempotency-key-header-04.txt
 Date: 16/11/2023
 Authors: Jayadeba Jena, Sanjay Dalal
 Working Group: Building Blocks for HTTP APIs (httpapi)
The HTTP Idempotency-Key request header field can be used to carry idempotency key in order to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant.
 REST API Media Types
 
 draft-ietf-httpapi-rest-api-mediatypes-05.txt
 Date: 07/01/2024
 Authors: Roberto Polli
 Working Group: Building Blocks for HTTP APIs (httpapi)
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml.
 The Link-Template HTTP Header Field
 
 draft-ietf-httpapi-link-template-04.txt
 Date: 01/04/2024
 Authors: Mark Nottingham
 Working Group: Building Blocks for HTTP APIs (httpapi)
This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated.
 Link relationship types for authentication
 
 draft-ietf-httpapi-authentication-link-01.txt
 Date: 03/03/2024
 Authors: Evert Pot
 Working Group: Building Blocks for HTTP APIs (httpapi)
This specification defines a set of relationships that may be used to indicate where a user may authenticate, log out, register a new account or find out who is currently authenticated.
 HTTP Link Hints
 
 draft-ietf-httpapi-link-hint-01.txt
 Date: 25/02/2024
 Authors: Mark Nottingham
 Working Group: Building Blocks for HTTP APIs (httpapi)
This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them.
 Byte Range PATCH
 
 draft-ietf-httpapi-patch-byterange-01.txt
 Date: 19/03/2024
 Authors: Austin Wright
 Working Group: Building Blocks for HTTP APIs (httpapi)
This document specifies a media type for PATCH payloads that overwrites a specific byte range, to allow random access writes, or allow a resource to be uploaded in several segments.
 api-catalog: a well-known URI and link relation to help discovery of APIs
 
 draft-ietf-httpapi-api-catalog-02.txt
 Date: 04/03/2024
 Authors: Kevin Smith
 Working Group: Building Blocks for HTTP APIs (httpapi)
This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of the APIs published by a given organisation or individual.


data-group-menu-data-url="/group/groupmenu.json"> Skip to main content

Building Blocks for HTTP APIs (httpapi)

WG Name Building Blocks for HTTP APIs
Acronym httpapi
Area Web and Internet Transport (wit)
State Active
Charter charter-ietf-httpapi-01 Approved
Document dependencies
Additional resources GitHub Repository
GitHub Organization
Zulip stream
Personnel Chairs Darrel Miller, Rich Salz
Area Director Francesca Palombini
Secretary Mark Nottingham
Mailing list Address httpapi@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/httpapi
Archive https://mailarchive.ietf.org/arch/browse/httpapi/
Chat Room address https://zulip.ietf.org/#narrow/stream/httpapi

Charter for Working Group

In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by 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 the following:

• Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields)

• Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects)

• 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 HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope.

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.

To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering.

This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue.

Milestones

Date Milestone Associated documents
Nov 2025 Enter WGLC draft-ietf-httpapi-authentication-link
Mar 2025 Enter WGLC draft-ietf-httpapi-patch-byterange
Jun 2024 Send to IESG draft-ietf-httpapi-deprecation-header
Jun 2024 Send to IESG draft-ietf-httpapi-api-catalog