Content Negotiation - Revision history

Thexa4 at 02:13, 19 January 2021

2021-01-19T02:13:38Z

← Older revision		Revision as of 19:13, 18 January 2021
Line 25:		Line 25:
	=== Return a List of Supported Formats When Sending a 406 Not Acceptable ===		=== Return a List of Supported Formats When Sending a 406 Not Acceptable ===
	Ideally these should link to [[API Viewer]] screens that show the response so users can explore the API in their browser.		Ideally these should link to [[API Viewer]] screens that show the response so users can explore the API in their browser.

			[[Category: Terminology]]

Thexa4 at 15:33, 15 January 2021

2021-01-15T15:33:33Z

← Older revision		Revision as of 08:33, 15 January 2021
Line 14:		Line 14:

	== Content-Language Negotiation ==		== Content-Language Negotiation ==
	Aside from negotiating the [[Content-Type Header \| Content-Type]] of the response, HTTP also allows clients to negotiate the ~~language~~ of the returned data. This is done in the same way as above but then with the [[Accept-Language Header]].		Aside from negotiating the [[Content-Type Header \| Content-Type]] of the response, HTTP also allows clients to negotiate the [[Content-Language]] of the returned data. This is done in the same way as above but then with the [[Accept-Language Header]].

			== Best Practices ==
			To make life easier for everyone we recommend following these practices:

			=== Return a <code>text/html</code> Response by Default ===
			Primarily if the request contains no Accept header or if the client asks for <code>/</code>. Ideally this should show a browser friendly interface or an [[API Viewer]].
			This allows users to use their browser to explore the data and makes it mandatory for clients to specify what response they want, an important step needed to allow [[Backward Compatibility]].

			=== Return a List of Supported Formats When Sending a 406 Not Acceptable ===
			Ideally these should link to [[API Viewer]] screens that show the response so users can explore the API in their browser.

Thexa4 at 15:11, 15 January 2021

2021-01-15T15:11:33Z

← Older revision		Revision as of 08:11, 15 January 2021
Line 9:		Line 9:
	# If there are common formats left, the server picks the one the client marked with the highest priority.		# If there are common formats left, the server picks the one the client marked with the highest priority.
	# The server then returns the content that matches the negotiated format.		# The server then returns the content that matches the negotiated format.

			== Wildcards ==
			Sometimes clients want to specify general classes that they accept. This can be done by using a <code></code>. This allows clients to request things like imge types: (<code>image/</code>), or anything at all: (<code>/</code>)

	== Content-Language Negotiation ==		== Content-Language Negotiation ==
	Aside from negotiating the [[Content-Type Header \| Content-Type]] of the response, HTTP also allows clients to negotiate the language of the returned data. This is done in the same way as above but then with the [[Accept-Language Header]].		Aside from negotiating the [[Content-Type Header \| Content-Type]] of the response, HTTP also allows clients to negotiate the language of the returned data. This is done in the same way as above but then with the [[Accept-Language Header]].

Thexa4 at 15:09, 15 January 2021

2021-01-15T15:09:21Z

← Older revision		Revision as of 08:09, 15 January 2021
Line 4:		Line 4:

	== Mechanism ==		== Mechanism ==
	1. When a client makes a request to a server it supplies all the formats it supports in the [[Accept Header]]: <code>Accept: text/html,application/xhtml+xml</code>.		# When a client makes a request to a server it supplies all the formats it supports in the [[Accept Header]]: <code>Accept: text/html,application/xhtml+xml</code>.
	2. The server looks at the list the client sent and excludes all formats it does not support.		# The server looks at the list the client sent and excludes all formats it does not support.
	3. If there are no common formats, the server either responds with [[406 Not Acceptable]] or it picks a fallback format like <code>text/html</code>.		# If there are no common formats, the server either responds with [[406 Not Acceptable]] or it picks a fallback format like <code>text/html</code>.
	4. If there are common formats left, the server picks the one the client marked with the highest priority.		# If there are common formats left, the server picks the one the client marked with the highest priority.
	5. The server then returns the content that matches the negotiated format.		# The server then returns the content that matches the negotiated format.

			== Content-Language Negotiation ==
			Aside from negotiating the [[Content-Type Header \| Content-Type]] of the response, HTTP also allows clients to negotiate the language of the returned data. This is done in the same way as above but then with the [[Accept-Language Header]].

Thexa4: Thexa4 moved page Content Type Negotiation to Content Negotiation

2021-01-15T15:07:07Z

Thexa4 moved page Content Type Negotiation to Content Negotiation

← Older revision	Revision as of 08:07, 15 January 2021
(No difference)

Thexa4 at 17:14, 14 January 2021

2021-01-14T17:14:08Z

← Older revision		Revision as of 10:14, 14 January 2021
Line 4:		Line 4:

	== Mechanism ==		== Mechanism ==
	1. When a client makes a request to a server it supplies all the formats it supports in the [[Accept Header]]: `Accept: text/html,application/xhtml+xml`.		1. When a client makes a request to a server it supplies all the formats it supports in the [[Accept Header]]: <code>Accept: text/html,application/xhtml+xml</code>.
	2. The server looks at the list the client sent and excludes all formats it does not support.		2. The server looks at the list the client sent and excludes all formats it does not support.
	3. If there are no common formats, the server either responds with [[406 Not Acceptable]] or it picks a fallback format like `text/html`.		3. If there are no common formats, the server either responds with [[406 Not Acceptable]] or it picks a fallback format like <code>text/html</code>.
	4. If there are common formats left, the server picks the one the client marked with the highest priority.		4. If there are common formats left, the server picks the one the client marked with the highest priority.
	5. The server then returns the content that matches the negotiated format.		5. The server then returns the content that matches the negotiated format.

Thexa4 at 17:12, 14 January 2021

2021-01-14T17:12:50Z

← Older revision		Revision as of 10:12, 14 January 2021
Line 1:		Line 1:
	A main feature of the HyperText Transfer Protocol (HTTP) is that it allows clients and servers to negotiate what kind of formats both support. They do this using the [[Accept Header]].		A main feature of the HyperText Transfer Protocol (HTTP) is that it allows clients and servers to negotiate what kind of formats both support. They do this using the [[Accept Header]].

	This allows implementation of APIs that are [[~~Backwards~~ Compatibility \| Backwards Compatible]] using [[Versioning#Content_Negotiation \| Content Negotiation Versioning]]. Additionally this feature can be used to serve modern image and video formats to clients that indicate support for it.		This allows implementation of APIs that are [[Backward Compatibility\| Backwards Compatible]] using [[Versioning#Content_Negotiation \| Content Negotiation Versioning]]. Additionally this feature can be used to serve modern image and video formats to clients that indicate support for it.

	== Mechanism ==		== Mechanism ==

Thexa4: Created page with "A main feature of the HyperText Transfer Protocol (HTTP) is that it allows clients and servers to negotiate what kind of formats both support. They do this using the Accept..."

2021-01-14T17:12:11Z

Created page with "A main feature of the HyperText Transfer Protocol (HTTP) is that it allows clients and servers to negotiate what kind of formats both support. They do this using the Accept..."

New page

A main feature of the HyperText Transfer Protocol (HTTP) is that it allows clients and servers to negotiate what kind of formats both support. They do this using the [[Accept Header]].

This allows implementation of APIs that are [[Backwards Compatibility | Backwards Compatible]] using [[Versioning#Content_Negotiation | Content Negotiation Versioning]]. Additionally this feature can be used to serve modern image and video formats to clients that indicate support for it.

== Mechanism ==
1. When a client makes a request to a server it supplies all the formats it supports in the [[Accept Header]]: `Accept: text/html,application/xhtml+xml`.
2. The server looks at the list the client sent and excludes all formats it does not support.
3. If there are no common formats, the server either responds with [[406 Not Acceptable]] or it picks a fallback format like `text/html`.
4. If there are common formats left, the server picks the one the client marked with the highest priority.
5. The server then returns the content that matches the negotiated format.