- Hi, I ve been reading a lot about how to do proper REST this week and the more I read, the more I m lost, especially the HATEOAS part I fear. First, to giveMessage 1 of 40 , Jul 27, 2011View SourceHi,
I've been reading a lot about how to do "proper" REST this week and the more I read, the more I'm lost, especially the HATEOAS part I fear.
First, to give some context, the company I work for develops mobile applications for clients. Most of the time, they want to get an iPhone native application, an Android application and a traditional Web based Application to cover the other mobile phones out there.
The way we are currently doing things is the good old (bad?) RPC over HTTP way. We define a bunch of URI which are coded inside the different apps, we exchange data as JSON, etc. This week, trying to do things in a better way, I've begin a more serious study of REST and how to do it properly.
What I really can't wrap my head around is how, technically, have HATEOAS in a native application? I mean, when building a native application, I have tables to display lists, buttons to do some things, etc. My understanding is that all those should be displayed based on the data (hypermedia) received from the server. Is that right?
A concrete example would be a hotel room rental service. The person would open the application and have fields to enter the from/to dates. It would then tap a "Get Available Rooms". The app would call the server and get back a list of rooms along with prices and other details. From there the person could select one room and rent it.
The RPC way of coding this is obvious to me but I have no idea how I'd do that in a proper REST way! What bugs me is that every way I look at it, the client application would still be tightly coupled to the service. I understand how I would only need to GET the http://rent-a-room.com URI hardcoded and then in the response I would have the http://rent-a-room.com/available-rooms URI given. But... My application would expect each "call" to return some pre-defined data and "rel", those can't appear out of the blue?!
I guess what I'm trying to say is that both the business process and the data exchanged must be known to my client application at the moment of coding it, and those can't change without breaking existing clients. But reading about REST, every is talking about loose coupling and not breaking clients... I just don't see it.
What am I missing?
Thanks a lot and sorry if it is a stupid question!
- [My apologies for missing this in the queue - Mark] Check out *REST in Practice*: Hypermedia and Systems Architecture http://t.co/VsVdObY via @oreillymediaMessage 40 of 40 , Jul 28, 2011View SourceCheck out REST in Practice: Hypermedia and Systems Architecture http://t.co/VsVdObY via @oreillymediaSpecially read chapters 3 through 5. Read it twice, thrice, ..... :)I myself is trying to understand HATEOAS. It is not easy but the more I read about it the more I begin to appreciate it.For whatever reason I think HATEOAS and Semantic Web are complimentary to each other. Alas I'm also not very good at understanding Semantic Web.My 2 cents.IqbalOn Thu, Jul 28, 2011 at 1:08 PM, Jason Erickson <jason@...> wrote:
I think you are probably asking Jan, but as far as I'm concerned, yes you fundamentally get it. Well said.On Jul 28, 2011, at 10:23 AM, Daniel Roussel wrote:
Sometimes, we can go on and develop a client solution using web apps, but sometime there is no way out and we need to do a native application.
I read some parts of Mr. Fielding thesis again and many of his comments on his blog and I think what wasn't clear (still not totally I fear) to me was what knowledge should be exposed "a priori" and what should be learned "a posteriori". My initial understanding was that "almost" nothing was to be known a priori and that did not make any sense because without some semantic knowledge of the received media, a client application can do nothing useful. What good is it to get a bunch of URI if I have no idea what they are!
Now, my understanding of it is that what MUST be known a priori are the Media Types which will be exchanged along with the possible relationship. A particular client would obviously be coded to support this/those media types. Just as a browser understands a resource of type text/html, image/jpeg, etc, my app would understand resources of type application/rent-a-room+xml for example.
This is the semantic knowledge needed to perform useful work. This is how a client knows what relation types to look for to navigate. This is how it can know what to present to the screen and how. So in essence, I believe that my theoretical "Room Rental" application could be compared to a web browser which handles "Rent-a-Rooms" documents instead of HTML documents. And what this means, is that this "Rent-a-Room" browser could navigate any server that is serving resources of the type "application/rent-a-room+xml" and on the flip side, a server could provide room rental services to anyone who understand this content type without anyone knowing any implementation details.
Am I far off or am I starting to get it a bit more?