You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How is a client (web frontend or another backend service) supposed to handle the person's href?
Should it be parsed, interpreted, cleaned up?
RESTful APIs are supposed to be self-describing and discoverable. So why is the curly braces part of the link's href?
Should this not just be a valid, addressable URI, without having to parse or extract the actual usable part?
Am I missing something here? How is the discoverability supposed to work here?
Furthermore the information on what is available is already present in the alps description.
There, an interested client can read up on what's possible, etc.
Thanks
The text was updated successfully, but these errors were encountered:
The format SD REST returns is HAL. Clients would usually use a library that understands that format. The templated field indicates that the href value is a URI template. The variant you show contains optional request parameters, so – again – a library that understands URI templates would know how to expand that template into a traversable URI with parameter values given or not.
Going forward, please use StackOverflow for such general questions. Chances are much higher you find someone answering as it's drawing a much bigger audience than the tracker here.
Hi
This is no issue but rather a question to understand the behaviour of Spring Data Rest.
Let's say I have an entity
Person
with the respective Repository extendingJpaRepository
.When acccessing the API's root URI, e.g.
There is a link of the form for the person's resource
How is a client (web frontend or another backend service) supposed to handle the person's href?
Should it be parsed, interpreted, cleaned up?
RESTful APIs are supposed to be self-describing and discoverable. So why is the curly braces part of the link's href?
Should this not just be a valid, addressable URI, without having to parse or extract the actual usable part?
Am I missing something here? How is the discoverability supposed to work here?
Furthermore the information on what is available is already present in the alps description.
There, an interested client can read up on what's possible, etc.
Thanks
The text was updated successfully, but these errors were encountered: