3 ms·

I wrote that question after reading the article, I am just not really understanding why an HTML response would be a better alternative to JSON. I thought the wh

I wrote that question after reading the article, I am just not really understanding why an HTML response would be a better alternative to JSON. I thought the whole reason JSON was used for RESTful API's due to the client-server principal. After rereading the article, if I understand what you are saying, the reason why the library was written was to address two failings with JSON based API's: They do not follow the HATEOAS requirement of REST and a JSON API may not have the same flexibility as raw SQL. To be honest, I am still a little confused and not really understanding what problem is being solved by the library... I am sorry.

carsongross 11y ago
OK, let me try to summarize: REST does not work well for JSON APIs This is because HATEOAS for JSON APIs never worked out JSON APIs will continue to move away from REST and towards RPC and SQL-like architectures However, if you wish to adopt a REST-ful architecture for your web application (and I think it is a good one for many applications), there is a good way to do so: have your server return bits of HTML, which naturally allows for HATEOS, and use a library like intercooler.js to fully embrace the concept. Does that clarify?
- rajangdavis 11y ago
  I did little research and now I understand why I was confused. JSON lacks hypermedia support which makes it violate HATEAOS (http://restcookbook.com/Mediatypes/json/ http://restcookbook.com/Mediatypes/json/ ); inherently, there can never be a RESTful, JSON API beca use it violates this principle. Everything I know about REST is wrong! Thanks for taking time to write out your response and this article, I was missing this one piece and couldn't wrap my head around it.
  - n0w 11y ago
    I'm not sure this is correct. Even the link provided does not exclude JSON as a media type. Just because there aren't (m)any examples of RESTful JSON API's doesn't mean there can't be. My understanding is that as long as you standardize the way in which hypermedia is communicated through the API, it could be RESTful.
    - virmundi 11y ago
      The REST paper desires to reuse existing doc types. If you create some linkable JSON, you've made a new type. So now everyone that wants to interact with your data has to first use your type. They will have to say Accepts:x-new-linky-json. Your type will probably be a bit different than someone else's linking JSON. So now we've got type explosion.
      - n0w 11y ago
        I don't advocate the creation of a new media type. My take on REST is that for an API to be RESTful, the API definition should really be the definition of a hypermedia format. The format definition then informs the interpretation of a hypermedia response such that state transitions can be made by the client. If our encoding of a hypermedia response is a JSON document, the format definition should describe how we can interpret that response to perform some action. If the service we provide is as general as a Web Page, then using a standardised format like HTML makes a huge amount of sense. If the service we provide is an API to some specific functionality, it seems reasonable to me that we can define the interpretation of some specific media type as a part of the specific hypermedia format that drives the interface. Then again my interpretation of REST could be completely backwards and I would appreciate corrections.
        virmundi 11y ago
        You cannot interpret a media type. They have a definite meaning.JSON does not have a linking ability. To make it, you've created a new mime type. REST is an interesting architecture. It can inform your decision. If you don't follow its prescriptions, you are not following REST. You are merely informed by it. That is fine. Don't confuse the two.

carsongross 11y ago

OK, let me try to summarize: REST does not work well for JSON APIs This is because HATEOAS for JSON APIs never worked out JSON APIs will continue to move away from REST and towards RPC and SQL-like architectures However, if you wish to adopt a REST-ful architecture for your web application (and I think it is a good one for many applications), there is a good way to do so: have your server return bits of HTML, which naturally allows for HATEOS, and use a library like intercooler.js to fully embrace the concept. Does that clarify?

rajangdavis 11y ago
I did little research and now I understand why I was confused. JSON lacks hypermedia support which makes it violate HATEAOS (http://restcookbook.com/Mediatypes/json/ http://restcookbook.com/Mediatypes/json/ ); inherently, there can never be a RESTful, JSON API beca use it violates this principle. Everything I know about REST is wrong! Thanks for taking time to write out your response and this article, I was missing this one piece and couldn't wrap my head around it.
- n0w 11y ago
  I'm not sure this is correct. Even the link provided does not exclude JSON as a media type. Just because there aren't (m)any examples of RESTful JSON API's doesn't mean there can't be. My understanding is that as long as you standardize the way in which hypermedia is communicated through the API, it could be RESTful.
  - virmundi 11y ago
    The REST paper desires to reuse existing doc types. If you create some linkable JSON, you've made a new type. So now everyone that wants to interact with your data has to first use your type. They will have to say Accepts:x-new-linky-json. Your type will probably be a bit different than someone else's linking JSON. So now we've got type explosion.
    - n0w 11y ago
      I don't advocate the creation of a new media type. My take on REST is that for an API to be RESTful, the API definition should really be the definition of a hypermedia format. The format definition then informs the interpretation of a hypermedia response such that state transitions can be made by the client. If our encoding of a hypermedia response is a JSON document, the format definition should describe how we can interpret that response to perform some action. If the service we provide is as general as a Web Page, then using a standardised format like HTML makes a huge amount of sense. If the service we provide is an API to some specific functionality, it seems reasonable to me that we can define the interpretation of some specific media type as a part of the specific hypermedia format that drives the interface. Then again my interpretation of REST could be completely backwards and I would appreciate corrections.
      - virmundi 11y ago
        You cannot interpret a media type. They have a definite meaning.JSON does not have a linking ability. To make it, you've created a new mime type. REST is an interesting architecture. It can inform your decision. If you don't follow its prescriptions, you are not following REST. You are merely informed by it. That is fine. Don't confuse the two.