Loading ...
Sorry, an error occurred while loading the content.
Skip to search.
 

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

Expand Messages
  • 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 1 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?



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