Closed Mec-iS closed 5 years ago
My 2¢ on this
Making the structure of IDs contractual between the client and the server is strengthening the coupling between them, which sounds like a bad idea in a hypermedia system.
In my experience, embedding semantics in IDs always comes back later to bite you when your system evolves (e.g., when you decide to add one field to your objects, which participates to their identity). That's why, in RDB, most people use auto-incremented opaque identifiers.
A better way for the client to discover the ID of an object would be, IMHO, to query the server for that object based on functional dependencies. E.g.: find the book with ISBN 123456 ; find all sensors on network X with serial number Y. That way, the client does not have to know how the server generates ID, and the server does not have to commit forever to a given way of generating IDs. All the server has to do is to provide the "search" functionality described above.
All the server has to do is to provide the "search" functionality described above
How computationally expensive can be to run this search often?
this discussion resulted in the creation of issue 302 linked above ^
@pchampin @Mec-iS
i would like to know how this search
functionality would work
@knakul853 pleasecheck hydra:search
in the vocabulary and the use of IRITemplate
Please take a look at the gitbook search scenario and Heracles.ts example taken from one of the integration tests.
In general, it is a quick link that can be used without any additional declarations. It should have an IriTemplate attached as a value so the request can be customized with some externally provided values (i.e. UI)
@alien-mcl thanks
As explained in a recent post in the mailing list: