4 ms·
> Do you have any resources showing what an API client for a "true REST" system would look like? … The idea of a computer application that has no context beyond
by eadmund 3y ago
> Do you have any resources showing what an API client for a "true REST" system would look like? … The idea of a computer application that has no context beyond an entry URL and a media type (text/html) is pretty hard for me and many like me to wrap our heads around.
Here is a very, very simple one. It uses a hypermedia format which uses JSON syntax, but has more requirements in order to be valid:
{
"account_number": 12345,
"balance": {
"currency": "usd",
"value": 100.00
},
"status": "good",
"deposits": "/accounts/12345/deposits",
"withdrawals": "/accounts/12345/withdrawals",
"transfers": "/accounts/12345/transfers",
"close-requests": "/accounts/12345/close-requests"
}
The key is that this is a media type (let’s call it application/example+bank-account) which defines a particular object schema, which includes certain properties whose values must be URL strings (it uses HTML’s relative-URL rules).
> once you've hard coded that it's not obvious what you gain by sending URLs instead of IDs.
Well, for one thing the client does not need to care about constructing URLs because it just follows them. The logic is just ‘grab the value of a key, verify that it is a URL, follow it’ rather than ‘remember an ID, use some implicit knowledge to construct a URL, follow it.’ It means that the server is free to delegate certain accounts to other servers. It makes federation a ton easier. It means that application code is able to live at a higher level.