There's no clear reason to pick a single representation; it's relatively easy to support a number of representations. The client should be permitted to demand a representation. There are several places where a client can specify the representation:

• The client can use a part of a query string, such as https://host/app/class/id/?form=XML. The portion of the URL after ? uses the form value to define the output format.
• The client can use a part of the URI, such as https://host/app;XML/class/id/. The app;XML syntax names the application, app, and the format, XML, by using a sub-delimiter of ; within the path.
• The client can use the https://host/app/class/id/#XML fragment identifier. The portion of the URL after # specifies a fragment, often a tag on a heading within an HTML page. For a RESTful request, the #XML fragment provides the format.
• The client can use a separate header. The Accept header, for example, can be used to specify the representation as part of the MIME type. We might include Accept: application/json to specify that a JSON-formatted response is expected.

None of these are obviously superior, but compatibility with some existing RESTful web services may suggest a particular format. The relative ease with which a framework parses a URI pattern may also suggest a particular format.

JSON is preferred by many JavaScript presentation layers. Other representations, such as XML or YAML, can be helpful for other presentation layers or other kinds of clients. In some cases, there may be yet another representation. For example, MXML or XAML might be required by a particular client application.

In the next section, we'll see how to use Flask to build a RESTful web service.