CODEWITHSUNDEEP
htmljsonrest
Andrius
Andrius

Reputation: 21118

REST - content type choice

We are making integration between three systems (lets call them A, B and C). A and B systems we can control, C we can not. Logic between three system is this - A communicates with B and B communicates with C. All use REST webservices. The one we can't control, use content type application/json. B for now use text/html, because there was older integration (with C) that had this used. With A there is no integration done at all.

So I'm wondering if its better to redo B system from scratch and make it use same content type application/json for every system or leave as it is (like there is not much of a difference)?

Also is there any advantages/disadvantages I should be avare of using application/json over html?

Update Sorry, I forgot to mention, it would be used solely to transfer business data if that is of any use.

Upvotes: 0

Views: 49

Answers (1)

RTigger
RTigger

Reputation: 1368

TLDR - Use JSON

Realistically when it comes to web services you should be serving out whatever the client asks for (and you support). Clients can specify what type of data they want to receive by using an HTTP Accept header, and it's up to your web service (or the web service framework you're using) to serialize the response accordingly.

When it comes to the difference between serving data using HTML or JSON, they're meant for two different use cases. HTML is sent with "markup" (the M in HTML) that includes instructions for how the data can be viewed, usually by a browser. For another client who isn't a browser and is just looking for the data, parsing this data is an extra unnecessary step that is usually not automatically supported without a 3rd party library or a bunch of manual code.

JSON (and XML and other formats like CSV) is meant to only transmit the data and its possible relations, and the deserialization is usually natively supported by a number of different client programming languages including .NET, JavaScript, and others. Because it's only the data, clients don't have to attempt to extract the data from any additional extraneous markup.

Also, it's a lot easier for a client web application to receive JSON and create HTML on the client side than it is to receive HTML and parse out only the data if needed. Plus you're allowing the client to create HTML that is specific to their application, rather than trying to manipulate HTML that the web service sent them to work with their specific app.

Upvotes: 2

Related Questions