| Name | Reference | Body | |
|---|---|---|---|
| Additional HTTP Status Codes | RFC 6585 | IETF | |
| This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. | |||
| Application-Level Profile Semantics (ALPS) | Internet Draft amundsen-richardson-foster-alps | IETF | |
| This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application-agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types. | |||
| HAL | |||
| HAL is a simple format that gives a consistent and easy way to hyperlink between resources in your API. | |||
| HTTP Immutable Responses | RFC 8246 | IETF | |
| The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified. | |||
| HTTP-client suggested Push Preference | Internet Draft pot-prefer-push | IETF | |
| "Prefer-Push" is a HTTP header that a client may use to request that a server uses HTTP/2 Push to send related resources as identified by their link relationships. | |||
| Health Check Response Format for HTTP APIs | Internet Draft inadarei-api-health-check | IETF | |
| This document proposes a service health check response format for HTTP APIs. | |||
| Home Documents for HTTP APIs | Internet Draft nottingham-json-home | IETF | |
| This document proposes a "home document" format for non-browser HTTP clients. | |||
| Hydra | Hydra Core Vocabulary | ||
| Hydra is a lightweight vocabulary to create hypermedia-driven Web APIs. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Authentication | RFC 7235 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Caching | RFC 7234 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests | RFC 7232 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | RFC 7230 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Range Requests | RFC 7233 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests. | |||
| Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | RFC 7231 | IETF | |
| The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. | |||
| Hypertext Transfer Protocol Version 2 | RFC 7540 | IETF | |
| This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. | |||
| JSON Merge Patch | RFC 7396 | IETF | |
| This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. | |||
| JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants | RFC 7523 | IETF | |
| This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. | |||
| JSON:API | |||
| If you’ve ever argued with your team about the way your JSON responses should be formatted, JSON:API can be your anti-bikeshedding tool. | |||
| JavaScript Object Notation (JSON) Patch | RFC 6902 | IETF | |
| JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents. | |||
| JavaScript Object Notation (JSON) Text Sequences | RFC 7464 | IETF | |
| This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A). | |||
| Metalink/HTTP: Mirrors and Hashes | RFC 6249 | IETF | |
| This document proposes a service health check response format for HTTP APIs. | |||
| OData Version 4.0 Part 1: Protocol | OASIS Standard odata-v4.0-part1-protocol | OASIS | |
| The Open Data Protocol (OData) enables the creation of REST-based data services, which allow resources, identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages. This specification defines the core semantics and the behavioral aspects of the protocol. | |||
| Prefer Header for HTTP | RFC 7240 | IETF | |
| This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request. | |||
| Preload | W3C TR http://www.w3.org/TR/preload | W3C | |
| This specification defines the preload keyword that may be used with link elements. This keyword provides a declarative fetch primitive that initiates an early fetch and separates fetching from resource execution. | |||
| Problem Details for HTTP APIs | RFC 7807 | IETF | |
| This document defines a "problem detail" as a way to carry machine-readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. | |||
| Siren | |||
| A hypermedia specification for representing entities. | |||
| System for Cross-domain Identity Management: Protocol | RFC 7644 | IETF | |
| The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. | |||
| The Deprecation HTTP Header Field | Internet Draft dalal-deprecation-header | IETF | |
| The HTTP Deprecation response header field can be used to signal to consumers of a URI-identified resource that the use of the resource has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional context for the deprecation, and possibly ways in which clients can find a replacement for the deprecated resource. | |||
| The Item and Collection Link Relations | RFC 6573 | IETF | |
| RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. | |||
| The OAuth 2.0 Authorization Framework | RFC 6749 | IETF | |
| The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. | |||
| The OAuth 2.0 Authorization Framework: Bearer Token Usage | RFC 6750 | IETF | |
| This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. | |||
| The Sunset HTTP Header Field | RFC 8594 | IETF | |
| This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset. | |||
| Web Linking | RFC 8288 | IETF | |
| This specification defines a way to indicate the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the use of such links in HTTP headers with the Link header field. | |||
Thank you!
Most of this content has come from the awesome community on our Slack channel, and webconcepts.info (thanks @dret!), and HTTP API Specs by Pedro Felix.