A browser is not coupled to a specific web site, so if tomorrow SO site changes we dont need to update the browser to use the new site. We may visit the redesigned site and rediscover how to perform the use cases we know we can perform. I understand there is not out-of-band information to be coded in the browser so we humans can use a specific web site.
Roy T. Fielding in REST APIs must be hypertext-driven states :
A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API).
Developing some application to manage recipes and using a REST API, a client of the API may want to update this receipt resource JSON representation:
{
"receipt":
{
"name": "Wan Tun Frito"
"Ingredients":
[
"Bread", "eggs", "pork sauce", "meat"
],
"time": 480
}
}
Then, if my understanding is accurate we have two options for a client consuming the REST API:
First option :
- A human user could consume the API REST the same way he can consumes a web site. It means there is a a initial URI but the browser instead rendering HTML presents the resource to the user according its media type (ie forms for JSON resources), and let the user to manipulate the presentation of the resource and submit the changes. Also the browser shows the hypertext controls presented in the resource representation if any allowing the user to navigate trhough the receipt application.
This way described above, the browser is not coupled to the server by only the prior knowledge of the HTTP protocol and JSON media type itself. This is how world wide web works as I understand.
But the media type JSON dont contain rules about how to present the resource. Presentation is not implicit in the representation of the resource and is not hold in the server. User interface is the responsability of the clients when separating concerns in a client-server architecture.
If the client app wants to highlight the name of the receipt when presenting it to the user its code need to be coupled to the JSON resource. If we change the key value "name": "Wan Tun Frito" with "title" : "Wan Tun Frito" in the receipt resource the application will fail presenting the resource.
Second option:
- If the user of the API is a coded program, then it may update the name of some receipt. Then its code should know about the resource receipt and also about its structure in JSON notation. This is out of band information as I understand. Then it is coupled with this out of band information in the code. Again if we change the key value "name": "Wan Tun Frito" with "title" : "Wan Tun Frito" in the receipt resource the client will fail.
Either way, there is a coupling between the code in the client and the server, and there is out of band information to use a REST API, so I dont understand what does it means that the client of a REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and the set of standardized media types
By standardized media type does it means building a standard media type other than JSON for receipts resource representation or does it means that the specific JSON structure we use to represent for our receipt resource is known beforehand by the client and server?.
Aucun commentaire:
Enregistrer un commentaire