Re:Use links not keys to represent relationships in APIs
by tuukkah on Sunday May 12, 2019 @06:17AM
(#19891082)
The identifier is not embedded in a URI, the identifier is a URI: instead of an integer id 1234 or a string id "1234", you can use a string id "http://example.com/id/1234". Typically, one service is responsible for creating the id but after that, it can be used to refer to the same entity in any number of services. EDIT: What makes it better than a free-format string id is that every person and tool knows how to de-reference it / look it up.
[ Parent
| on HN ]
Re:Use links not keys to represent relationships in APIs
by jeltz on Sunday May 12, 2019 @09:29AM
(#19891759)
What determined which API owns a resource when the same resource is exposed in mutlipe apis (e.g you have a REST API and a AMQP feed)? In some cases it is obvious but in other cases it is far from clear.
I feel using urls as ids create more problems than it solves, especially if you use absolute urls. I have worked with cases where the same ID was used in 3 or 4 different APIs. None of them clearly the master.
Re:Use links not keys to represent relationships in APIs
by tuukkah on Sunday May 12, 2019 @02:19PM
(#19893514)
The URI doesn't have to be fully owned by any single microservice. The JSON representation can more or less correspond to a HTML view and be served by the UI, or a separate API facade can combine the relevant pieces of information from various microservices.