How to use standard or custom HTTP headers
REST Resources
Entities SHOULD be served with an ETag header. |
Caching
ETag, If-None-Match |
| 3.5 HTTP Headers |
3.6.1 POST
Location header |
Resource lifecycle
either If-Unmodified-Since or If-Match |
Versioning
Clients may specify a desired version as the v parameter of the Accept header |
Versioning
If the version was unspecified, the server should use the latest available version, and specify the Vary header |
Internationalisation (i18n)
Localisation is inherently a representation concern, and HTTP mandates such concerns to be addressed using protocol headers. |
Single-entity GET endpoints
Responses should include a Last-Modified or ETag header, and may include both |
Compression
Servers may support the Accept-Encoding header for compression purposes, but this is not mandatory. |
| Expires HTTP Header |
| https://github.com/Haufe-Lexware/api-style-guide/blob/master/caching/caching.md#cache-control-header |
| ETag |
| Require Versioning in the Accepts Header |
| Support ETags for Caching |
| Provide Request-Ids for Introspection |
| Divide Large Responses Across Requests with Ranges |
POST
POST operations SHOULD support the Location response header |
| Options and link headers |
| Standard request headers |
| Standard response headers |
| Custom Headers |
| Specifying headers as query parameters |
Naming Conventions
Every HTTP Header should use Hyphenated-Pascal-Case. A custom HTTP Header SHOULD NOT start with X- (RFC6648). |