Jan 6, 2009


I think designing a REST URL is really challenging The resources are represented as hyperlinks.When REST applications are to be designed do business logic states depend on REST URL design ? The changes in application state are done through hyperlinks.So every possible state of applications are exposed as services and state changes are also exposed as urls.So we can draw a graph depicting change in states.So the transitions are done at run time while using the application.It is decided by the server.So the hypermedia as the engine of application state (HATEOAS) becomes a design constraint.So if the server responds as a set of links depicting the transitions, the consumer client can traverse through them to arrive at the final state... Concept seems pretty straightforward, but are there any underlying implementation complexities ? The relationship between resources can be logical, but the server makes relationships for the application.The client can have states defined by hypermedia elements.The tags like IMG,OBJECT,SCRIPT embeds resource within itself.The CSS can have image background links.So these urls can locate to the resource globally.The name space is defined by web itself.I think the scene becomes more interesting when web service discoveries,ordering of interactions, business logic making the client dynamic by the features of this concept.The libraries and frameworks as we know provide a way to call a single function and the system itself calls other functions internally.So this form of calling a single URL as a an entry point for calling other related urls linking logic or resource states performs same functionality like an interactive website.The urls can change at any time.The urls become a constraint in designing for a dynamic application.There will be a tight coupling for the resources and the client due to these permanent urls which will have to be residing forever.So the solution ? The response can be documents of urls for the client to traverse as i mentioned above as to call the resource from a single entry point... which is what HATEOAS is about

With a truly REST based architecture you are free to change just about anything about the disposition and naming of resources in the system, except for a few well known start point URIs. You can change the URI shapes (for example, if you decide that you really hate the currently scheme). You can relocate resources to different servers (for example, if you need to partition you data). Best of all, you can do those things without asking any ones permission, because clients will not even notice the difference.


No comments:

Post a Comment