Disclaimer
This maybe total nonsense I am 90% sure it is but I’m putting it here anyway coz:
1-I believe my blog hasn’t been indexed by Google -I haven’t linked it to any website yet- so it doesn’t officially exist on the Web :) The only person that might be reading this besides me is my supervisor. Sorry Dr Dave :).
2-If one day I feel like releasing this to the world then hopefully I would have came up with something to make up for this nonsense
3-I might delete this post someday :)
4-Putting up here makes me more keen on finding the solution.
------------------------------------------------------------------------
Interested in REST I was thinking that it can’t just be about providing hyperlinks and accessing them in a uniform way. There must be more to it, especially because it is a PhD dissertation. I’ve read some chapters of Fielding’s dissertation or to be accurate skimmed through them.
The thing that I can’t quite get was statelessness and “Hypermedia as the engine of application state” which are related I think.
I understood what they meant, but not why they were important.
Questions
Q1-Do we make “fat clients” that store the state of the application?
Q2-Or do we make the messages fat by storing everything about the state in them?
Q3-Or do we have a hyperlink for every possible transition? But where are these hyperlinks stored and processed? At the server? Ok isn’t that storing the application state at the server? Does that defy REST?
Possible Answers:
A1-If we made clients fat; that removes the storage and processing burden from the server to the client. But is that desirable? Isn’t the fact that servers having more power, why clients sometimes choose to use servers? In case of the Web that is OK because there isn’t much processing involved? However if I have a server offering heavy analysis of client provided data that needs to interact with the client during the analysis can that be decoupled? Or are there applications in which REST is favoured and others where it isn’t?
The question holds also for things that we don’t trust the client to do such as authenticating a credit card.
A2-Making messages fat. That would burden the server too. And the communication media? And at the end hinder the server from responding to more messages.
A3-It offers visibility as stated in the dissertation but what else?
The greatest application for REST after the web is Web Services (currently). Yet although picked up by the WS community. I don’t see any adoption from Fielding himself towards RESTful Web Services? Why not? Isn’t this another testbed for his ideas. Or is he fed up with people and companies using it as a buzzword.
Or is it to offer RESTful Web Services (with the benefits REST claims) you need a REST architecture not just an interface. Which may currently be unavailable? But the Web is RESTful, Web Services are built on top of it or should be.
To find answers my queries I need to :
1-Go back and read Fielding’s dissertation.
2-Go back and read the RESTful Web Services book by Leonard Richardson and Sam Ruby.
3- Read this post again and again http://blogs.sun.com/craigmcc/entry/why_hateoas
This maybe total nonsense I am 90% sure it is but I’m putting it here anyway coz:
1-I believe my blog hasn’t been indexed by Google -I haven’t linked it to any website yet- so it doesn’t officially exist on the Web :) The only person that might be reading this besides me is my supervisor. Sorry Dr Dave :).
2-If one day I feel like releasing this to the world then hopefully I would have came up with something to make up for this nonsense
3-I might delete this post someday :)
4-Putting up here makes me more keen on finding the solution.
------------------------------------------------------------------------
Interested in REST I was thinking that it can’t just be about providing hyperlinks and accessing them in a uniform way. There must be more to it, especially because it is a PhD dissertation. I’ve read some chapters of Fielding’s dissertation or to be accurate skimmed through them.
The thing that I can’t quite get was statelessness and “Hypermedia as the engine of application state” which are related I think.
I understood what they meant, but not why they were important.
Questions
Q1-Do we make “fat clients” that store the state of the application?
Q2-Or do we make the messages fat by storing everything about the state in them?
Q3-Or do we have a hyperlink for every possible transition? But where are these hyperlinks stored and processed? At the server? Ok isn’t that storing the application state at the server? Does that defy REST?
Possible Answers:
A1-If we made clients fat; that removes the storage and processing burden from the server to the client. But is that desirable? Isn’t the fact that servers having more power, why clients sometimes choose to use servers? In case of the Web that is OK because there isn’t much processing involved? However if I have a server offering heavy analysis of client provided data that needs to interact with the client during the analysis can that be decoupled? Or are there applications in which REST is favoured and others where it isn’t?
The question holds also for things that we don’t trust the client to do such as authenticating a credit card.
A2-Making messages fat. That would burden the server too. And the communication media? And at the end hinder the server from responding to more messages.
A3-It offers visibility as stated in the dissertation but what else?
The greatest application for REST after the web is Web Services (currently). Yet although picked up by the WS community. I don’t see any adoption from Fielding himself towards RESTful Web Services? Why not? Isn’t this another testbed for his ideas. Or is he fed up with people and companies using it as a buzzword.
Or is it to offer RESTful Web Services (with the benefits REST claims) you need a REST architecture not just an interface. Which may currently be unavailable? But the Web is RESTful, Web Services are built on top of it or should be.
To find answers my queries I need to :
1-Go back and read Fielding’s dissertation.
2-Go back and read the RESTful Web Services book by Leonard Richardson and Sam Ruby.
3- Read this post again and again http://blogs.sun.com/craigmcc/entry/why_hateoas
No comments:
Post a Comment