Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion to avoid distinction between retrieving a rel via _embedded or _links #34

Open
eterps opened this issue Oct 21, 2014 · 5 comments

Comments

@eterps
Copy link

eterps commented Oct 21, 2014

Consider this example where a GET request to https://example.org/blog-post at one point in time responded with (situation A):

{
  "_links": {
    "self": { "href": "https://example.org/blog-post" },
    "author": { "href": "https://example.org/people/alan-watts" }
  },
  "_embedded": {
    "author": {
      "_links": {
        "self": { "href": "https://example.org/people/alan-watts" }
      },
      "name": "Alan Watts",
      "born": "January 6, 1915",
      "died": "November 16, 1973"
    }
  }
}

And some while later (or earlier) with (situation B):

{
  "_links": {
    "self": { "href": "https://example.org/blog-post" },
    "author": { "href": "https://example.org/people/alan-watts" }
  }
}

If you consider the Hypertext cache pattern, you could see the embedding as an optional optimization, and your client code shouldn't have to check whether a "rel" is embedded or not for every possible resource.

So for example Resource("https://example.org/blog-post").author.name is the same for both situation A and B (but in situation B it would result in an extra request being done).

See also https://github.com/gamache/hyperresource as a (Ruby) example of one way this distinction can be avoided in client code.

@pbcomm
Copy link

pbcomm commented Oct 21, 2014

It's a nice feature and it does follow hypermedia guidelines, however it can be very costly to do that on the browser side. Large datasets that require 50+ fetches will crash any browser. In any case it is very possible to build that in.

@eterps
Copy link
Author

eterps commented Oct 21, 2014

I will think about possible solutions to prevent the request snowball effect. Thank you for your consideration.

@pbcomm
Copy link

pbcomm commented Oct 21, 2014

You should also take into the account that these extra calls would have to be made synchronously (even if not many), stopping other processes. Rendering and any other functionality will be delayed. One win for doing this from what I saw, is being alerted immediately that the services are being slammed by requests and something is wrong.

@pezra
Copy link
Contributor

pezra commented Nov 4, 2014

The #related method added in #35 allows consumers to navigate links regardless of whether the link is in the _embedded or _links section. That would make @eterps' example look like

blog_post_resource.related("author").props["name"]

Is that close enough to close this issue?

@mmolhoek
Copy link

for example traverson has the follow function, which does just that as far as i know. would be a great addition to hyperagent i think, but @pezra, i think you are right. it sounds like thats the one we need :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants