Android, REST, and HATEOAS constraint
Asked Answered
S

1

6

So I'm building a mobile app which will be using a RESTful web service (which I am also writing myself) After lots of research I have a few questions regarding mobile apps and the HATEOAS constraint.

  1. I usually use the Gson library for parsing objects without the HATEOAS constraint and it has been proven to be really efficent. For HATEOAS however, I am thinking of using Gson for the deserialization and Json-HAL for the response format.

    How do I parse all of the _links and _embedded resources in my application without making the deserialization process tiresome? Some objects could have "embedded" resources and some don't. How should I create my data model objects to support all of these new tags? I am pretty lost on this part so I would appreciate an example.

  2. Does anyone have any tips implementing this constraint on mobile apps?

  3. If you think HAL or Json is not the right choice for mobile, please let me know.

Implementing this constraint for mobile seems like overkill to me.

Please enlighten me, Thanks!

Saldivar answered 25/8, 2014 at 17:0 Comment(1)
So, did you manage to solve this problem? I'd like to hear about your solution. Post it as an answer to this question and accept your own answer?Pointless
E
0

Bit late to the party, but I feel that the best way to solve this is, summed up:

  • Yea HAL is a good format.
  • Treat things in _links and things in _embedded both as links. They are really the same 'thing'.
  • The difference with _embedded compared to _links though, is that _embedded really should pre-populate your cache. So whatever you receive their should be added to some kind of cache which should make future GET requests unneeded for those resources.

The benefit of this approach is that it now becomes possible for the server to 'promote' links from _links to _embedded and have your client automatically adapt to this and make less HTTP calls.

References: (disclaimer, I wrote both)

Edithe answered 20/4, 2017 at 14:46 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.