5 ms·

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 does

by 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.

by n0w 11y ago

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.