1

I have read a few articles about HATEOAS and the way that API should be implemented such that you can traverse to different states by following the links. But I'm confused as to how the client should be implemented?

From this answer:

The client knows nothing about how the server designs its URIs other than what it can find out at runtime.

  • Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?
  • What would be the purpose of API documentation then?
Community
  • 1
  • 1
Sam R.
  • 16,027
  • 12
  • 69
  • 122

3 Answers3

2

For implementing HATEOAS server needs to include links to responses that goes from server to client, and client uses these links in response to communicate to server.

For eg. Client request Product list, server will respond with list of products with link to Add, edit and delete the products (if user is able to do that), which will then be transformed in client into links or buttons like Edit Product, Delete Product.

This blog might help you get more understanding.

Guanxi
  • 3,103
  • 21
  • 38
1

Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?

Yes unless the root page does not contain the link which describes the POST.

What would be the purpose of API documentation then?

It describes the metadata the client can recognize for example by a link or by a property. So it describes the capabilities of the service.

inf3rno
  • 24,976
  • 11
  • 115
  • 197
1

To answer your first question "Does the client need to crawl from the root node down to a nested resource to just make a POST if it doesn't know the direct URI?"

The answer is No. The client always does not have to crawl from the root node. It is possible to design the URI;s such a way that the navigation to reach the direct URI can be from other views. For example if the purpose of the URI (/Products/product1/Delete) is to delete product , then it should be possible to reach this by either crawling from the /Products or by giving a namespace query of Products/Deleteview. This "DeleteView" URI should give all the URI's of the delete view. i.e it can return a uri collection like Products/product1/Delete, Products/product2/Delete etc.

To your second Question "What would be the purpose of API documentation then?" Concept of API is a legacy of the past. Ideally the URI itself should be the documentation. This way the client can be programmed to discover and take only things that it can respond to.

We got hold of unique technology which manages these namespaces. so we are shielded from this view manipulation ourselves. I recommend using a technology to manipulate and create these URI namespaces.

Antony gonzalves
  • 126
  • 1
  • 1