HATEOAS bookmarked URL access

Question

I am trying to get my head around HATEOAS.

Let's work through an example. A client loads up a browser to getemails.com. To make it simple, let's assume that a call to getemails.com, hits the server and it returns back with a list of emails. Each email has a link that will the allow the user to get more details. Something like this:

{[
    {
        "id": "1",
        "subject" : "subject something",
        _links:[
            "email":"http://getemails.com/emaildetail/1"
        ]
    }
    {
        "id": "2",
        "subject" : "subject something else",
        _links:[
            "email":"http://getemails.com/emaildetail/2"
        ]
    }
]}

This is displayed to the user on a table. The user then clicks on a row, and the client code, will get the email url from under the _links of the selected row and make a call to the server. It will then update the page (assuming SPA) with the email details. It will also update the address to getemails.com/#email/1

Now what if the user bookmarks getemails.com/#email/1 location? Since the client app has not loaded the list of emails to begin with, how will it know that the url to call the server with to get more info is emaildetail/1?

Rounding

Answer 1

your problem is that you aren't being truly RESTful. Exposing inner workings like an id field is trap you should avoid. That ID is only meaningful inside of your service, it should not be propagated outside of it as you have done.

instead use a self link to each of your resources, so when you request the "email" relationship you should be getting back an email resource (presumably)

{
  "subject" : "subject something",
  "text" : "yadda yadda yadda...",
   "from" : "[email protected]",
   _links:{
       "self":"http://getemails.com/emaildetail/1"
   }
}

use that self url in your SPA's fragment identifier. now when the user bookmarks that full url getemails.com/#http://getemails.com/emaildetail/1 (with some URL encoding) your app will know what resource to retrieve and present.

Eleni

Agreed. Exposing the id was not right. But is the only way to bookmark? The http fragment will look ugly wont it? – Rounding

yeah it'll be ugly, but that's a key tenant of RESTful architecture. The implementation to retrieve a resource (URL) should be completely opaque to the client. Its the perfect place to shove state. The whole pursuit for "pretty urls" is rather misguided. – Eleni

It's more than ugly. It exposes details of the server and its API that are not appropriate to expose. Is there another solution? I'm finding that the benefits of HATEOAS are fast being outweighed by this ugliness. – Commorancy

i don't see how it exposes details of a server – Eleni