Building Blocks for HTTP APIs (httpapi) Proposed WG

WG Name Building Blocks for HTTP APIs
Acronym httpapi
Area Applications and Real-Time Area (art)
State Proposed
Charter charter-ietf-httpapi-00-02 External Review (Message to Community, Selected by Secretariat)
Dependencies Document dependency graph (SVG)
Personnel Chairs Darrel Miller 
Rich Salz 
Area Director Barry Leiba 
Editor 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/
Jabber chat Room address xmpp:httpapi@jabber.ietf.org?join
Logs https://jabber.ietf.org/logs/httpapi/

Charter for proposed 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.

New work items can be added after a Call for Adoption on the working group mailing list and consultation with the Area Director. To assess whether the group is functioning well in this mode, this charter will be reviewed by the IESG nine months after chartering.

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 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.