Re:Use links not keys to represent relationships in APIs
by niftich on Sunday May 12, 2019 @10:22PM
(#19895990)
You as the client try to GET /my-receipts/20190512-1 from Fancy Receipt Scanning Service, and content-negotiate with an Accept header to "text/plain" or "image/gif" (e.g. to get a plain copy or a scan). There's no agreed-upon way of communicating links in plain text or GIF, so Fancy Receipt Scanning Service can't serve you a GIF scan of your receipt that links to a product page for every item you bought.
If you accepted "text/html", it could have served HTML that embedded these links within the response body, but you didn't accept "text/html".
It can choose to send links as headers, if it still wishes to communicate links.
Re:Use links not keys to represent relationships in APIs
by yawaramin on Monday May 13, 2019 @07:33PM
(#19905156)
That's fair, but if I'm defining an API that serves, say, JSON, I can define a schema for it and tell my clients what things mean in the schema, including which things are links.
If you accepted "text/html", it could have served HTML that embedded these links within the response body, but you didn't accept "text/html".
It can choose to send links as headers, if it still wishes to communicate links.