Hypermedia API Crawl Link and Practicality

Question

I am trying to create a hypermedia API. Everything looks good. Say when I get /books/isbn/12313441213 , I get something like this:

 <book> <id>123</id> <name>Hypermedia APIs</name> <description>Basic api design techniques</description> <tags> <tag>rest</tag> <tag>api</tag> <tag>service</tag> </tags> <authors> <link rel="author" uri="/authors/id/22" /> <link rel="author" uri="/authors/id/18" /> </authors> </book> 

Now I can get around the authors from this resource. When I get /books/by/author/id/18 , I get something like this:

 <books> <book id="123"> <name>Hypermedia APIs</name> <link rel="self" uri="/books/id/123" /> </book> <book id="191"> <name>Chef Recipes for Rails Developers</name> <link rel="self" uri="/books/id/191" /> </book> <book id="220"> <name>Rails 4 Cookbook</name> <link rel="self" uri="/books/id/220" /> </book> <book id="292"> <name>Ruby 102</name> <link rel="self" uri="/books/id/292" /> </book> <book id="432"> <name>Semantic Architecture</name> <link rel="self" uri="/books/id/432" /> </book> <book id="501"> <name>Service Oriented Design</name> <link rel="self" uri="/books/id/501" /> </book> </books> 

Which also seems to work just fine for me. Is this method of uri patterns good or not, my question is how practical is it to go through such links?

Given that you want the resource to be in full depth (including information about the author), you must make at least 3 calls to the server. Again, to collect, you have to make tons of calls to the server. Yes, maybe I could use the resource extension here, but why should I use hypermedia links in general, since all my clients will use the extended resources on time.

I understand that we are collecting lots, allowing clients to navigate links (i.e. if customers build relationships based on discovery resources, they will affect the minimum when the api changes, or they are forced to get the latest scheme from the resource of the endpoint itself etc.). Again, the practicality of this approach or the implementation of this approach will kill the system.

Either I'm not getting something in hypermedia api design, or hypermedia api sounds great, but it seems like it's just a theoretical idea, not a practical one.

Any thoughts on this?

Answer 1

This is a very important issue. Actually one more big question: who knows that the bypass refers to a specific resource R?

For example, to get to the book-detail resource, the client must make a call to write your api, for example, “/”, and then use rel “book categories”, get uri for book categories, then make a call in OPTIONS to see if it’s possible whether the GET operation on this resource, then get the categories of books, then get a link to the resource "books in categories", etc., which ultimately goes to the resource "book-detail". This path to resource R should be part of customer knowledge. But don't re-encode the urls, just read the urls at runtime. This considers the human-to-human scenario. Inefficiency still exists. In the case of a machine-to-machine scenario, a machine starting with "/" can go through your API and do some processing for your resources. If an automaton must reach all the resources in a tree (or can be a state machine), then there is no inefficiency. But if the machine needs to make a call to a resource in the tree, and it knows only the entry point of the API, then it will encounter the problem of accepting several calls to reach this point.

Many people will tell you to enter caching using etags and / or memcached, but caching is an increase in performance, you can not depend on caches by 100% because caches become obsolete, so in these cases the code for moving R1 resources to Rn should be in your client.

check my question: https://stackoverflow.com/questions/15214526/why-hypermedia-api

But to answer the question of practicality: if you have a business stream in which the client must go to resource R1, then R2 then ... Rn, and you want to provide this stream, hypermedia is practical. I assume that there are no direct calls to Resource Rx, but through R1 → R2 → ... Rx-1.

Answer 2

It would be more traditional to use parameters:

GET / books? author = 18

I would expect the answer to be more like:

Hypermedia API

You can also use the parameter to specify which fields on subresource you want to see. Sort of

GET / books / 18? expand = author (name, birthday)

which will return the author’s name and birthday as part of the author’s tag in the response. Then you can provide a reasonable default on how many users of information about the author get when they request a book (maybe only the author’s name and the author’s name), but they can get more detailed information if they want by changing the parameter.

Those kinds of settings can help reduce the number of calls that need to be made.

Another observation is that many of this data can be cached either on the client or on intermediate proxies. Most likely, a lot will change with respect to the book or the author, so these resources can allow the client to cache them for a long period of time. Then there is no round trip - the client ends up in his local data cache.