CODEWITHSUNDEEP
restcontent-type
Ahmad Karimpour
Ahmad Karimpour

Reputation: 64

RESTful web service - does supporting single content type break any standard?

My mind is busy with the following question. I want to create a RESTful web service that works with XML data instead of JSON (for no particular reason).

Would this violate any RESTful standard?

Upvotes: 0

Views: 41

Answers (1)

stackh34p
stackh34p

Reputation: 9009

The REST protocol does not enforce you with the representation format of the data. In fact, the format of the data being transferred between the server and client is irrelevant, as long as:

  • The server is capable of producing the requested format.
  • The client is capable of reading the format produced by the server.
  • No information (essential to the data object being transferred) is lost in producing the desired format

This makes the use of JSON or XML a choice of convenience (in terms of how the data is rendered and later used). You are free to choose either of these, or even another format - there are no strict standards to how the data is represented.

In general, the REST protocol allows (and encourages) supplying headers for the requested content type (usually Accepts, also Content-Type if you are sending data). Therefore, the same RESTful service should be able to work with any valid content type. It is a good practice to implement RESTful services to be agnostic of the content type and be capable of supporting multiple formats. XML and JSON are being the most popular and widely adopted, thus it is somewhat desirable to support both. Choosing anything different will result in a limitation to your service's clients (the consumers of the service) - they need to recognize and parse the format to the required data object on their side.

In addition, there is a popular approach of using custom content types, which are based on existing formats. So, instead of JSON (application/json) it is often seen to have vendor/mycompany.specialformat+json which is de-facto JSON but with some metadata (like API versioning) embedded in the content type. You can even produce different JSON structure using the same RESTful service, and it is all fine as long as each different representation is mapped to its own content type. For instance vendor/mycompany.specialformat+json may render the same object, but in a different structure compared to vendor/mycompany.anotherformat+json, yet both formats be a valid JSON.

The bottom line is - the data being transferred should not depend on the representation format. Make a distinction between the data object sent/received trough the RESTful service, and the way it is serialized (formatted). For technical reasons, you may choose to provide only one way of formatting the data - XML for example. This would not violate any standard, but will limit the usage of the service to only XML-capable clients. On the other hand, supporting various format may introduce more complexity on the server-side, as probably additional logic has to be written, as the same data should be properly serialized to the new format. Also, supporting various data types is a way to make it easier for your service's clients to request the format they will integrate with more easily - it is up to you to decide if you'd provide such capability.

Upvotes: 2

Related Questions