format precedence while content negotiation

gistfile1.txt

>Rails picks up the expected format from the query parameter format, or if not there from the URL path suffix, or it not there from the Accept header

Blog post: https://dzone.com/articles/rest-with-rails-part-2-serving

>format query parameter is useful for rendering JSON output from a web browser without
special tools to modify the Accept header

IBM knowledge base: https://www.ibm.com/support/knowledgecenter/en/SS4GCC_6.1.1/com.ibm.urelease.doc/topics/rest_api_ref_conventions.html

>However, if a request uses multiple methods simultaneously,
then the HTTP parameter (query string) takes precedence and the HTTP Accept
header will be ignored.

API: https://services.faa.gov/docs/formats/

>Rule: Media type selection using a query parameter may be supported
To enable simple links and easy debugging, REST APIs may support media type
selection via a query parameter named
accept
 with a value format that mirrors that of the
Accept
 HTTP request header. For example:
GET /bookmarks/mikemassedotcom?accept=application/xml
This is a more precise and generic approach to media type identification that should
be  preferred  over  the  common  alternative  of  appending  a  virtual  file  extension
like .xml to the URI’s path.
The virtual  file extension approach binds the resource and
its representation together, implying that they are one and the same

[REST API Design Rulebook](https://doc.lagout.org/programmation/Webservers/REST%20API%20Design%20Rulebook%20-%20Masse%20-%20O%27Reilly%20%282012%29/REST%20API%20Design%20Rulebook%20-%20Masse%20-%20O%27Reilly%20%282012%29.pdf#%5B%7B%22num%22%3A179%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2Cnull%2C537.94385%2Cnull%5D)
In our case this is `format` parameter

>Should the media type change based on Accept headers or based on the URL?
To ensure browser exportability, it should be in the URL.
The most sensible option here would be to append a .json or .xml extension to
the endpoint URL

[Best Practices for Designing a Pragmatic RESTful API](https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api). He is designer API and Founder of [Enchant](https://www.enchant.com/)  (Zendesk?)

>The query string parameter solves the issue in the context of a developer
testing the API in a browser. Adding a query parameter is trivial, configuring
your browser to send a different set of Accept types is difficult if possible
at all.

[github discussion](https://github.com/strongloop/strong-remoting/issues/118#issuecomment-60376621)

```
curl -uadmin:admin "http://localhost:8080/alfresco/service/hellouser.json"
curl -uadmin:admin "http://localhost:8080/alfresco/service/hellouser?format=json"
curl -uadmin:admin -H "Accept: text/html" "http://localhost:8080/alfresco/service/hellouser"
```
[Documentation how to select format](http://docs.alfresco.com/4.0/tasks/ws-response-format-select.html) and based on this [SO question](https://stackoverflow.com/q/49363343/4632019)

>The API returns JSON as the default content type. This can be overridden by using the format query string parameter with the value json, jsonp, or xml. The API also respects Accept header entries (EX: application/json, application/xml), with precedence given to the format parameter.

[Someone's API](http://data.bioontology.org/documentation#nav_content_types)