61–70 of 118 posts
> Ignoring status codes My favorite is when everything returns a 200, but the response is something like: { status: "fail", error: "forbidden" } Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.
Earlier quoted context omitted.
Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start). REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON w…
> REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design. Especially if it's not worth the effort.
Yes, waterfall was a mistake, but design-nothing is mistaken too. Thinking before doing helps avoid waste & rework.
Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense? What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more…
Most use POST for that now, but there is room, or should be room for RPC-style endpoints in a mostly REST service, and vice-versa.
Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for? What if you can't shoehorn your functionality into the handful of REST verbs? What if none of the status codes make sense? What ever happened to plain old RPC? Have we stopped to consider that people tunnel things through POST or GET requests because it's easier and more…
REST doesn't have a handful of verbs, HTTP has a handful of predefined verbs (but supports extensions). REST is an architectural style that does not specify the underlying protocol.
> What if none of the status codes make sense?
Again, that's an HTTP issue not a REST issue. And it's not likely to be a real issue (HTTP status codes may be insufficiently precise—but already support additional data for disambiguation—but I can't imagine a situation where none of them make sense.)
Earlier quoted context omitted.
Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data. I ask because I'm going to start writing my first http api for a small SPA.
As a shorthand, think of REST as about nouns, and RPC about verbs. /account/1 is REST because the you're looking for an account (noun), the account id is 1, and you're using the HTTP method GET. /search/hello is RPC because it uses a specific verb (search) to call a remote procedure to search for the 'hello' keyword. You're taking an action for which there is no appropriate HTTP method, so RPC can be used instead of…
Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.
Earlier quoted context omitted.
Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.
HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example. Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.
Well, HTTP itself is the archetypical REST API, though.
The problem is that people want an RPC mechanism, and REST gives them a document transfer mechanism. If your API will never be navigated by a human operating a browser, a lot of the REST specification is inapplicable (navigation links, etc.) So you're throwing out a lot of REST regardless, and the question becomes where to draw the line between ease of implementation and compliance with a standard that doesn't really…
Another problem is that people want an RPC mechanism, when what they need is a state-transfer mechanism. It turns out that the semantics of RPC — attractive as they undeniably are — are pretty poor for building real-world distributed systems, while those of REST as a pretty good (or at least better ) fit.
Personally I like to very selectively add RPC actions on top of the base resource. Tacking an RPC action onto the resource URI allows you to encapsulate the intent of the user's action, handle all the updates required server side, and then return the updated representation.
Earlier quoted context omitted.
Another problem is that people want an RPC mechanism, when what they need is a state-transfer mechanism. It turns out that the semantics of RPC — attractive as they undeniably are — are pretty poor for building real-world distributed systems, while those of REST as a pretty good (or at least better ) fit.
People need both. REST works well for CRUD operations that don't have complex side effects or constraints. What's often missing in this is intent. I just want to do "the thing" to this particular account or whatever. Personally I like to very selectively add RPC actions on top of the base resource. Tacking an RPC action onto the resource URI allows you to encapsulate the intent of the user's action, handle all the up…
So it's usually POST resource/:id/action and that's fine.
Earlier quoted context omitted.
There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.
Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data. I ask because I'm going to start writing my first http api for a small SPA.
the main difference is endpoint negotiation vs object state transfer - consider an account representation - if you can withdraw, the link to perform the withdraw operation is there in the server response. if you can't, the link to the withdraw operation is not there. this is how the returned value convey the object state and how it let client explore object operarions.
say, it's the difference between returning an object instead of a struct, and it's also why json alone is not compatible with rest, there's not an agreed schema to identify operations coming along with the data so that a client can actionit - json-ld and hal can, if you reallyhate the idea of xml tho.
> Ignoring status codes My favorite is when everything returns a 200, but the response is something like: { status: "fail", error: "forbidden" } Sometimes they even include the 403 in the response, almost like the developer is giving you a giant middle finger.
That leads to cleaner code for the frontend frameworks, better interoperability and simpler debugging. Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I run in to this all the time and once we adopted it (for all our APIs), life has been better for customers and our internal teams.
I guess google, facebook, microsoft and all the others are doing it wrong then? Or Improperly according to you? Because they do not respond with a 200 on application level errors in their APIs.