Loading ...
Sorry, an error occurred while loading the content.
 

Re: [rest-discuss] REST and HATEOAS in the context of native applications?

Expand Messages
  • Berend de Boer
    ... 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
    Message 1 of 40 , Jul 27, 2011
      >>>>> "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
      HATEOAS.

      Using properly named urls and verbs will already give most of the
      benefits.


      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/
    • Iqbal Yusuf
      [My apologies for missing this in the queue - Mark] Check out *REST in Practice*: Hypermedia and Systems Architecture http://t.co/VsVdObY via @oreillymedia
      Message 40 of 40 , Jul 28, 2011
        Check out REST in Practice: Hypermedia and Systems Architecture http://t.co/VsVdObY via @oreillymedia

        Specially 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.

        Iqbal

        On 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?



      Your message has been successfully submitted and would be delivered to recipients shortly.