Use links not keys to represent relationships in APIs

Re:Use links not keys to represent relationships in APIs by kabes on Sunday May 12, 2019 @12:29PM (#19892861)

The document also forgets that API's are not read-only. So let's say you have users and usergroups and you can request a usergroup with its list of users and you can add users to usergroups.

If you use links for read, you should also use them for writes, otherwise it's quite inconsistent. So now you need to add a lot of parsing everywhere to extract the id's out of the urls, just for the sake of being more dogmatic

[ Parent | on HN ]

Re:Use links not keys to represent relationships in APIs by mpnally on Monday May 13, 2019 @07:55PM (#19905303)

I have implemented many APIs in this style, both read and write. Depending on the design of the storage layer, the server may or may not have to parse ids out of URLs. The client never has to; for the client, the URL is the only Id.

[ Parent | on HN ]

Re:Use links not keys to represent relationships in APIs by treve on Sunday May 12, 2019 @02:33PM (#19893602)

Just a thought:

If in your example your usergroup and user are managed by the same service, then usually you should already have a feature in your framework that parses `/user/123` into its individual component and finds the relevant entity.

Ideally you would use that.

[ Parent | on HN ]