Re: [rest-discuss] REST and HATEOAS in the context of native applications?
>>>>> "Daniel" == Daniel Roussel <daniel@...> writes:Daniel> Hi, I've been reading a lot about how to do "proper" REST
Daniel> this week and the more I read, the more I'm lost,
Daniel> especially the HATEOAS part I fear.
There are levels of REST, so I suggest you don't worry too much about
Using properly named urls and verbs will already give most of the
Daniel> I guess what I'm trying to say is that both the business
Daniel> process and the data exchanged must be known to my client
Daniel> application at the moment of coding it, and those can't
Daniel> change without breaking existing clients. But reading
Daniel> about REST, every is talking about loose coupling and not
Daniel> breaking clients... I just don't see it.
Daniel> What am I missing?
Daniel> Thanks a lot and sorry if it is a stupid question!
It isn't, but I myself don't worry too much about this. If your URLS
are stable, and you provide redirects, your server can serve clients
for longer than they will exist in many cases.
All the best,
Berend de Boer
Awesome Drupal hosting: https://www.xplainhosting.com/
- Check 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?