This chapter differs from the chapters before in the sense that the author's major focus is on describing an architectural style instead of a particular project. To a person with very limited experience in web applications, I feel the brilliance of REST is in addressing data like documents. It has an Unix resonance to it (where data is addressed like files). Just as in Unix one can do "cat /proc/1234" to retrieve information on a particular process, here one can retrieve http://server/employee/1234" to get information on an employee. Through just a few HTTP operations, the syntax supports the various operations on the data effectively. What's even better here is that the HTTP protocol supports providing information on the physical representation of the returned data and thus a client can present it correctly.
The author also envisions that a server can determine the amount of data to return based on the role or permission of a client. This gets me thinking, can a client specify the amount of data it wants? This surely would save network resource. Instead of a client receiving the whole data and then has to filter out the interesting portions, the server can just skipping them. On the other hand, to support such functionality it may cause unnecessary intimacy between the client and the server (client now needs to know the "views" of data the server can provide).
Subscribe to:
Post Comments (Atom)
 
No comments:
Post a Comment