For a system to be RESTful it must adhere to constraints of having a uniform interface and using hypertext as the engine of the application state. In the light of these constraints we will describe how EXPRESS is RESTful, first by showing how it has a uniform interface, then by discussing how it can use hypertext to change states. The examples explained are from EXPRESS.
According to Fielding having a uniform interface means: “having a unique resource identifier mechanism, having access methods with the same semantics for all resources, resources are manipulated by exchanging representations and messages for actions and representations are self descriptive.”[1]
In EXPRESS a resource is a class, an instance or a property, each one of them has a URI. And the access methods that can be applied are (OPTIONS, GET, PUT, DELETE and POST). Having the same semantics with the relation to resources we can realize a pattern illustrated in the following table
According to Fielding having a uniform interface means: “having a unique resource identifier mechanism, having access methods with the same semantics for all resources, resources are manipulated by exchanging representations and messages for actions and representations are self descriptive.”[1]
In EXPRESS a resource is a class, an instance or a property, each one of them has a URI. And the access methods that can be applied are (OPTIONS, GET, PUT, DELETE and POST). Having the same semantics with the relation to resources we can realize a pattern illustrated in the following table
| Resource | OPTIONS | Semantics |
| Class in an ontology | GET | Gets the structure of the class |
| POST | A factory endpoint to create instances of this class | |
| Instance or property | GET {only} | Read only instance or property |
| Instance or property | GET, PUT, DELETE | Modifiable instance or property |
But taking this to a higher level of semantics, does the system respond internally to posting an order in the same way it responds to posting a customer? Then the answer is no. And we believe it is still RESTful because the semantics here are inferred from the shared understanding of the ontology, or in RESTful terms, the representations.
As for manipulation of resources by exchanging representations, this is done in EXPRESS. For example to modify a customer a representation of the customer in OWL or RDF is PUT to the customer’s URI. And messages are self-descriptive in the sense that they contain the method and the representation. The representation whether it is OWL or RDF is inherently self-describing.
For the other constraint of REST which is hypertext as the engine of the application state. Fielding describes it as: “each response contains a partial representation of server-side state, some representations contain directions on how to transition to the next state and that each steady-state (page) embodies the current application state.”
For an example of the response containing part of the application state, invoking GET on a resource returns a representation of that resource, which is part of the application state. Another example is when invoking POST on a URI representing a class, a generated URI of an instance of that class is returned, which is part of the application state (a new instance/resource is created). However when invoking a PUT on an instance to modify the resource, the message sent by the client contains the modified resource but the response -in EXPRSS- from the server doesn’t. This can be modified easily to make the server respond by sending a representation of the modified instance if the modification is accepted. But the question is, is that a requirement of REST? Is what Fielding means by the response: a response by either the server or the client and in that case EXPRESS is already RESTful, or does he mean that all responses from the server must contain part of the application-state? Another question is what is the impact of this constraint? Answering this question may guide us to the answer of the previous one.
Regarding the other statement, “some representations contain directions on how to transition to the next state”, this can be accomplished through the OWL file, since it states what the client can do with the resources. Another example is when a client wants to create a new resource, it POSTs to a class’s URI, a new generated URI for an instance of that class is sent back to the client, the client can use that URI to move to the other state which is PUTting the instance’s content to it.
For the last statement “each steady-state (page) embodies the current application state”, I am not quite sure how that works, it may be that the representation the server sends to the client contains the current application state.
I believe the picture right now is still quite vague; going into implementation may clarify it more.
[1] Roy T. Fielding, A Little REST and Relaxation, JAZOON’07 The international Conference on Java Technology, 24-28 June, 2007, Zurich.
http://www.parleys.com/display/PARLEYS/A+little+REST+and+Relaxation
As for manipulation of resources by exchanging representations, this is done in EXPRESS. For example to modify a customer a representation of the customer in OWL or RDF is PUT to the customer’s URI. And messages are self-descriptive in the sense that they contain the method and the representation. The representation whether it is OWL or RDF is inherently self-describing.
For the other constraint of REST which is hypertext as the engine of the application state. Fielding describes it as: “each response contains a partial representation of server-side state, some representations contain directions on how to transition to the next state and that each steady-state (page) embodies the current application state.”
For an example of the response containing part of the application state, invoking GET on a resource returns a representation of that resource, which is part of the application state. Another example is when invoking POST on a URI representing a class, a generated URI of an instance of that class is returned, which is part of the application state (a new instance/resource is created). However when invoking a PUT on an instance to modify the resource, the message sent by the client contains the modified resource but the response -in EXPRSS- from the server doesn’t. This can be modified easily to make the server respond by sending a representation of the modified instance if the modification is accepted. But the question is, is that a requirement of REST? Is what Fielding means by the response: a response by either the server or the client and in that case EXPRESS is already RESTful, or does he mean that all responses from the server must contain part of the application-state? Another question is what is the impact of this constraint? Answering this question may guide us to the answer of the previous one.
Regarding the other statement, “some representations contain directions on how to transition to the next state”, this can be accomplished through the OWL file, since it states what the client can do with the resources. Another example is when a client wants to create a new resource, it POSTs to a class’s URI, a new generated URI for an instance of that class is sent back to the client, the client can use that URI to move to the other state which is PUTting the instance’s content to it.
For the last statement “each steady-state (page) embodies the current application state”, I am not quite sure how that works, it may be that the representation the server sends to the client contains the current application state.
I believe the picture right now is still quite vague; going into implementation may clarify it more.
[1] Roy T. Fielding, A Little REST and Relaxation, JAZOON’07 The international Conference on Java Technology, 24-28 June, 2007, Zurich.
http://www.parleys.com/display/PARLEYS/A+little+REST+and+Relaxation
No comments:
Post a Comment