-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
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. |
I will think about possible solutions to prevent the request snowball effect. Thank you for your consideration. |
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. |
Consider this example where a GET request to https://example.org/blog-post at one point in time responded with (situation A):
And some while later (or earlier) with (situation B):
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.
The text was updated successfully, but these errors were encountered: