31–40 of 393 posts
It turns out that using JSON is easy, has good support and is relatively compact on the wire.
It also turns out that using HTTP verbs and transferring the entire state of an object makes development easier.
And equally, for 99% of use cases, it turns out that HATEOAS is nice but not necessary.
I feel old for I have witnessed many of these battles. But I feel that I have seen history. There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes). It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normativel…
That goes for technology, words, political concepts, music...
The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…
REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionally rare. Access will nearly always be done programmatically, at which point a lot of the cruft of REST is unnecessary.
It's plumbing.
Some time in the future there will be another level of the software revolution in which alot of those details can be left to the computers themselves to work out.
The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…
I wish I could upvote this 100 times. REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionally rare. Access will nearly always be done programmatically, at which point a lot of the cruft of REST is unnecessary.
It was literally extracted from the browser’s interaction model so… kinda?
Great article. Calling APIs RESTful because they return JSON has always been a peeve of mine. But here's the question though, why do APIs need to be RESTful? What is the need for a client to have no knowledge of the server, if the server can also provide logic that can run on the client. In some sense, one could argue that a service that provides both raw data and client logic to transform raw data to hypermedia, is…
IMHO, they've wildly missed the mark. APIs, as colloquially known, can't be RESTful as they define it because the client systems aren't AI based and can't follow links. To use their example: Account number: 12345 Balance: $100.00 USD Links: deposits withdrawals transfers close-requests I can navigate to that page and because I know English can follow links to my withdrawls and deposits. A computer can't. The client p…
Rest never denied that coupling, it defined that coupling at the content-type level.
Great article. Calling APIs RESTful because they return JSON has always been a peeve of mine. But here's the question though, why do APIs need to be RESTful? What is the need for a client to have no knowledge of the server, if the server can also provide logic that can run on the client. In some sense, one could argue that a service that provides both raw data and client logic to transform raw data to hypermedia, is…
IMHO, they've wildly missed the mark. APIs, as colloquially known, can't be RESTful as they define it because the client systems aren't AI based and can't follow links. To use their example: Account number: 12345 Balance: $100.00 USD Links: deposits withdrawals transfers close-requests I can navigate to that page and because I know English can follow links to my withdrawls and deposits. A computer can't. The client p…
* Localization * Accessibility * Different clients * Different presentations for different contexts.
The whole premise of RESTful hyper-media driven APIs described in this article is predicated on "The One" client talking to the server. Our modern world is not this.
Earlier quoted context omitted.
Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?
200 OK but actually you have an error from a pretend-REST API is my number one "old man yells at clouds" thing that drives me nuts. It is fundamentally disrespectful to the users of the API. Especially if you have metrics/alerts that are tracking status codes.
This is the point though. As a client I don't want to throw 400 errors. As a server I don't want to throw 500 errors nor some 400 error.
As an example, if either client or server sees a spike of 404 errors they want to investigate. When the result of that investigation is "some crawler went haywire" or "a user is trying to access resources that don't exist" it's annoying. So the 200 OK with an error is an attempt to stop those sorts of scenarios. Of course like anything people take it too far but there's decent logic behind it.
The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…
The client "knows nothing about the meaning of the responses" only inasmuch as it intentionally abstracts away from that meaning to the extent practicable for the intended application. Of course, the requirements of a human looking at some data are not the same as those of a machine using that same data in some automated workflow.
Linked Data standards (usable even within JSON via JSON-LD) have been developed to enable a "hyperlink"-focused approach to these concerns, so there's plenty of overlap with REST principles.