Implement support for the HATEOAS constraint about restkit

[blakewatters]

There are certainly some interesting capabilities on this point. I've
captured a note into Pivotal. There are a number of higher items on my
priority list than conforming to the letter with the definition of REST. If
you are interested in contributing some work in pursuit of this goal, I'm
happy to talk design. Otherwise I think this is likely a post-1.0 TODO.

On Mon, Apr 4, 2011 at 9:25 AM, andrashatvani <
[email protected]>wrote:

According to Roy Fielding:

"REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of application
state." [1]

The first three are incorporated by RestKit (although it seems to couple
REST to HTTP), but the latter one is missing. Namely, there is no built-in
support for links representing possible state transitions or resource
relationships, but rather the related entities need to be embedded or to be
asked for with isolated queries based on id's.

"...if the engine of application state (and hence the API) is not being
driven by hypertext, then it cannot be RESTful and cannot be a REST API.
Period. " [2]

I think most people entirely miss the HATEOAS constraint, because most
frameworks neither enforce, nor support the usage of them. Changing this for
RestKit could improve the quality of and finally enable REST for
wannabe-rest-systems.

Reply to this email directly or view it on GitHub:
https://github.com/twotoasters/RestKit/issues/39

Blake Watters
Two Toasters | CTO
[email protected]
[phone]

[andrashatvani]

I understand that the stability and reliability of the infrastructural components and layers of RestKit is at the moment more important than this constraint. Even JAX-RS will support HATEOAS with version 2.0 at the earliest.
But I'll happily contribute as time allows, because I think that really the frameworks are which should enforce true RESTfulness. Should the Google group be used for the related discussion or is there any other preferred way?

[blakewatters]

Google Group is the best place for discussion. I'd love to pick this back up on list to discuss possible designs for implementation. Pivotal and Github Issues seem to only be monitored by me.

[blakewatters]

This is important and we should add it now that OM 2.0 is done.

[duhanebel]

@blakewatters I've look on google group but I couldn't find any recent discussion about this. Is any development/analysis going on on this topic?

[blakewatters]

I have done some thinking and design work on what's remaining for this to
really be considered 'done' but there is not an active discussion.

On Mon, May 20, 2013 at 4:21 PM, Fabio [email protected] wrote:

@blakewatters https://github.com/blakewatters I've look on google group
but I couldn't find any recent discussion about this. Is any
development/analysis going on on this topic?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-18170137
.

To stay sane & productive, I don't live in e-mail. If you need to reach me
quickly, try this link: https://awayfind.com/blakewatters

[shouze]

Hi @blakewatters what's up about RKPaginator with links ?

We plan to make a REST Api wich returns HATEOAS payloads looking like :

{
  "Pagination": {
     "per_page": 10,
     "total_objects": 250,
     "total_page": 25,
   },
   "MyOjectCollection": [...]
   "Links": {
      "current": "http:…………….",
      "next": "http:…………….",
      "previous": "http:…………….",
      "last": "http:…………….",
   } 
}

So, do you think it's already possible with actual RKPaginator or that it's time to contribute to RestKit to support this kind of feature ?

[blakewatters]

This is definitely where I have been planning to take things. The metadata mapping was another step in this direction -- enabling the use of headers to send down rel links for traversal.

Another major piece for this that I have been working on the design for is to ditch the custom pathPattern notion in favor of the URI Template emerging standard.

Where I want to wind up for 1.0 is that you can send down complete URLs or templates as headers or values within the payload and use them to discover/load related resources without requiring router configuration.

I would certainly accept a patch that enables the paginator to use server-provided URL's in addition to the pattern based system it currently supports.

In general, I think the paginator needs to see another refresh during the 1.0 development cycle.

[shouze]

@blakewatters ok I imagine you're talking about link in http header the github fashion: http://developer.github.com/v3/#pagination

I think we can manage that and try to implement it, I'll probably soon have some more questions to make things the right way. I'll take a look at metadata mapping internal 1st.

Btw RKPaginator interface don't need to much changes I think. Maybe the init? Maybe you can tell me what kind of RK object I can pass to use header link value for example?

- (id)initWithRequest:(NSURLRequest *)request paginationMapping:(RKObjectMapping *)paginationMapping responseDescriptors:(NSArray *)responseDescriptors

I've seen the - (void)setMappingMetadata:(NSDictionary *)mappingMetadata method in RKResponseMapperOperation but I don't know atm how to exploit that kind of meta.

[shouze]

I'm ready to work on paginator improvements to support HATEOAS.

So could you take few minutes to answer my questions in the previous comment & help me bootstrapping my contribution? ping @blakewatters

[danpalmer]

What's the status of HATEOAS support here? In my mind, this is the most important part of "REST", especially given that using HTTP gives you most of the constraints for free, and I was disappointed to find that a library called "RestKit" doesn't support some of the core concepts of REST.

I'd like to explore adding support for Hypermedia controls, but I've never used RestKit before. Would anyone be interested in helping out with this?