I’ve been reading to answer the questions in my last post, and the picture is a bit clearer.
I think I now understand what we gain by HATEOAS. Instead of the client guessing where to go throughout an application by constructing URIs, it is guided by the server by providing it with hyperlinks (representations) to follow.
What do we gain from that?
More decoupling, thus more reusability, less likeliness of clients to break.
So that is HATEOAS, but what is statelessness.
The application state is on the client, because the client is keeping track of where it is and what it is doing. The server doesn’t need to do that.
In the book RESTful Web Services the authors differentiate between two types of states application state and resource state. Resource state is on the server and application state is on the client.
So in my case of ordering a pizza, should the order be a resource created by the client on the server, therefore a resource state? Or should it be part of the application state and should be stored on the client side?
There are some things to note here:
-In my pizza delivery there would be another client interested in the resource, the carrier service so having the order on the client that would not be very efficient.
-Scalability issues, having the order on the server won’t be as scalable and reliable as having the order on the client. In the RESTful Web Services book the authors wrote, “When your application is stateless you don’t need to coordinate activities between servers, sharing memory or creating “server affinity” to make sure the same server handles every request in a session you can throw web servers at the problem until the bottleneck becomes access to your resource state. Then you have to get into database replication, mirroring or whatever strategy is most appropriate for the way you have chosen to store your resource state”. My problem with that is that mostly what clients would deal with in Web Services are resource states, or are we thinking about resources in a wrong way.
-I believe the problem boils down to who creates resources in the book the clients could create resources, however in the dissertation, to the best I know Fielding didn’t mention that clients could create resources on the server. He referred to creators of resources as authors which I assume have control over the server. So if the client can create resources on the server, then the server is storing part of the application state which according to what I understood from Fielding's dissertation isn't RESTful.
-Also in the dissertation there is an example of a shopping cart “A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping basket” within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase.” I think that if this was implemented using the RESTful Web Services book way then a client would create a shopping cart at the server then post items to it which won’t be as scalable as Fielding’s client side shopping basket.
Difference between REST and ROA
By REST I am referring to Fielding’s dissertation, and by ROA I am referring to the RESTful Web Services book.
-In REST there is no CRUD. It states that a uniform interface should exist but not what it is.
-In REST there is more emphasis on HATEOAS.
-In ROA there is more emphasis on uniform interface: GET, PUT, POST and DELETE.
-ROA uses the HTTP protocol and its methods to implement RESTful Web Services. In REST a set of constraints are set but not tied to any protocol or system.
-Web Services are not mentioned in REST, but they are the heart of ROA.
Limitations of REST
As stated by Fielding in his dissertation:
“The REST interface is designed to be efficient for large grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”
“not optimal for other forms of architectural interaction” so why the fuss about RESTful Web Services? They are not transferring large grain hypermedia? Is it that the WS community saw in REST what Fielding didn’t see?
Another limitation which was pointed out by “Triple Space Computing” researchers when considering REST as an infrastructure is that there isn’t a way for the server to send notifications to clients asynchronously.
I think I now understand what we gain by HATEOAS. Instead of the client guessing where to go throughout an application by constructing URIs, it is guided by the server by providing it with hyperlinks (representations) to follow.
What do we gain from that?
More decoupling, thus more reusability, less likeliness of clients to break.
So that is HATEOAS, but what is statelessness.
The application state is on the client, because the client is keeping track of where it is and what it is doing. The server doesn’t need to do that.
In the book RESTful Web Services the authors differentiate between two types of states application state and resource state. Resource state is on the server and application state is on the client.
So in my case of ordering a pizza, should the order be a resource created by the client on the server, therefore a resource state? Or should it be part of the application state and should be stored on the client side?
There are some things to note here:
-In my pizza delivery there would be another client interested in the resource, the carrier service so having the order on the client that would not be very efficient.
-Scalability issues, having the order on the server won’t be as scalable and reliable as having the order on the client. In the RESTful Web Services book the authors wrote, “When your application is stateless you don’t need to coordinate activities between servers, sharing memory or creating “server affinity” to make sure the same server handles every request in a session you can throw web servers at the problem until the bottleneck becomes access to your resource state. Then you have to get into database replication, mirroring or whatever strategy is most appropriate for the way you have chosen to store your resource state”. My problem with that is that mostly what clients would deal with in Web Services are resource states, or are we thinking about resources in a wrong way.
-I believe the problem boils down to who creates resources in the book the clients could create resources, however in the dissertation, to the best I know Fielding didn’t mention that clients could create resources on the server. He referred to creators of resources as authors which I assume have control over the server. So if the client can create resources on the server, then the server is storing part of the application state which according to what I understood from Fielding's dissertation isn't RESTful.
-Also in the dissertation there is an example of a shopping cart “A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. Likewise, the use of cookies to identify a user-specific “shopping basket” within a server-side database could be more efficiently implemented by defining the semantics of shopping items within the hypermedia data formats, allowing the user agent to select and store those items within their own client-side shopping basket, complete with a URI to be used for check-out when the client is ready to purchase.” I think that if this was implemented using the RESTful Web Services book way then a client would create a shopping cart at the server then post items to it which won’t be as scalable as Fielding’s client side shopping basket.
Difference between REST and ROA
By REST I am referring to Fielding’s dissertation, and by ROA I am referring to the RESTful Web Services book.
-In REST there is no CRUD. It states that a uniform interface should exist but not what it is.
-In REST there is more emphasis on HATEOAS.
-In ROA there is more emphasis on uniform interface: GET, PUT, POST and DELETE.
-ROA uses the HTTP protocol and its methods to implement RESTful Web Services. In REST a set of constraints are set but not tied to any protocol or system.
-Web Services are not mentioned in REST, but they are the heart of ROA.
Limitations of REST
As stated by Fielding in his dissertation:
“The REST interface is designed to be efficient for large grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.”
“not optimal for other forms of architectural interaction” so why the fuss about RESTful Web Services? They are not transferring large grain hypermedia? Is it that the WS community saw in REST what Fielding didn’t see?
Another limitation which was pointed out by “Triple Space Computing” researchers when considering REST as an infrastructure is that there isn’t a way for the server to send notifications to clients asynchronously.
No comments:
Post a Comment