What is the source of knowledge for the client about fields, where they can read link to the entity?
For human it's obvious that dog has an owner, so field "owner" should be used, but for code - you need to write it, "document it".
So if you're going to "document" every field containing link to external resource, you'll end up with even more code, than just "documenting" API endpoints.
Also, pretty often you need multiple IDs of entities to send POST/PUT request - just to create a relation.
POST /adoption, owner_id=5, dog_id=7.
How should it look with links? Will it be issue for the server to parse them? And it's just simple case with 1 to 1 relation, sometimes you need to add sets of objects to another entity.
It's a really bad advice and after reading this I'm not sure I should trust other articles from that source.
Because it's more difficult than parse "5" and "7", especially when you need to parse not only numeral IDs. "More difficult" always means "more bugs" and "more vulnerabilities".
There is no single reason for this complication. The ONLY motivation author had - less knowledge about API endpoints on the client. But simultaneously it means more knowledge about the fields where links are stored, so it doesn't save nothing.
For human it's obvious that dog has an owner, so field "owner" should be used, but for code - you need to write it, "document it". So if you're going to "document" every field containing link to external resource, you'll end up with even more code, than just "documenting" API endpoints.
Also, pretty often you need multiple IDs of entities to send POST/PUT request - just to create a relation.
POST /adoption, owner_id=5, dog_id=7.
How should it look with links? Will it be issue for the server to parse them? And it's just simple case with 1 to 1 relation, sometimes you need to add sets of objects to another entity.
It's a really bad advice and after reading this I'm not sure I should trust other articles from that source.