REST's 'resource communication mechanisms' and 'on-the-fly' improvement of a client's knowledge of them -
I am trying to come up with REST, as defined by Roy Fielding. Recently I am trying to wrap my mind around:
The concept I have is in this quote:
Transition can be determined by the customer's knowledge (or limited) of media type and resource communication system, both of which can improve flight (e.g., code-on-demand).
Specifically, what is the knowledge of "resource communication system", how is this knowledge described in the document / specs and is an intention? Then, how would it be best to improve that knowledge? I think I understand addressing the 'knowledge of customer type of media'
I have some estimates (put, gate, etc.) but for any suggestions, examples or pointers for the restime API It would be appreciated, which clearly solve the problems in that quote. If it helps, I am thinking about these issues in the context of HTTP + JSON, so I appreciate REST that HTTP + * is not limited to
Sun Cloud API is already Quoted as a nice cool design, I did not know how or how these specific issues were addressed - maybe the wood is not seen for trees?
Explanation:
What are the puzzles to me if PUT, GET, etc. These are the mechanisms, it shows a client that some & lt; Media-type & gt; To apply specific hyperlinks within, and it looks delicate, and suggest hypertext-link map (directly) for resources.
resource communication system
"by resource communication mechanism", I believe That Roy is referring to HTTP requests and HTTP verbs. He is only saying this without specifying for HTTP because REST is not dependent on HTTP. I would say that for all 99.99% of reverse services, the document of resource communication system has been done in.
The Sun Cloud API meets these requirements because all the customers need to use the API, for the words of requests and returned media types, for example if a client does not understand what type of document If type is in application / vnd.com.sun.cloud.Cloud + json
then it will not be able to use the API.
It is in comparison to the services and does not define the new media type, but assumes that a client knows how to remove domain data from the Atom feed and the client is based on those rules. But the URI is expected to build the URI space, it is in direct violation of Roy's recommendations.
Corrected on the fly
To be honest, I can only guess what Roy is telling here, I can imagine a scenario where based on user input Javascript could be downloaded for url creation. This server can be prevented from generating the URL for each element in the list explicitly.
In addition, some legitimate changes can be enabled or disabled based on user input. Consider the situation where you do not want to enable the submit button unless the user has entered all the necessary fields. Recovered documents contain links to allow transition, but downloaded code controls and when the user can select the link.
The downloaded code can also be used to dynamically change the action on the link. If you want to edit a resource, then it can do a GET, if you want to delete that resource, then you DELETE it will only allow one link to be represented, but many actions Will be able to.
Comments
Post a Comment