1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication
2. that using those semantics is better than not, when communicating over HTTP
This shouldn’t be controversial! Want GraphQL? Cool, ?foo[bar]=quux. Want a special data transport format? Cool, Content-Type: application/furby. Want a big blob of different content? Multipart has your back.
There’s nothing special about REST. Use the format! The only special thing is you have to… use it. POST / everything ain’t that. Sure it’s convenient for your custom format that doesn’t interop with anything. And then it’s a decade of articles about no one using common standards. Welp, this standard was here all along.
> This is the exact opposite of what people usually do...
Indeed, because the people that actually build stuff figured that none of these constraints are beneficial absent a magical smart client that will never exist. People implement HTTP-RPC APIs. They call the result "REST API" for buzzword compliance, which turns out to be quite important. The nitpickers that insist on bringing more REST concepts like HATEOAS into the API only make things worse to use.
It's a similar situation to Alan Kay lamenting that most "object-oriented" language don't implement what he had in mind. The people that get stuff done just don't care. The people that do care build exotic systems that the rest of us just don't want to use.
the emphasis on resources as a low level 1 idea really sold me here.
urls- names for resources- are an axiomatic core part of the web. rest definitely emphasized that things have names, that we are using verbs to interact with individual things. dont get a /team get /team/42. now you've transfered that representation to you. i see this core idea of the web being made up of resources as fairly absent from the discussion here, or talked around, but martin did a good job really putting a pin on how basic, hiw essential resources are.
the real worlds restfulness start to breakdown when we look at how many objects have real urls in them. often the state has some id's. team may have an account id. but rest suggests this should likely be a url instead.
works like Marcel Weiher's In-process ReST work to make the server-side more restful, more url oriented. As opppsed to perhaps altering id's on the way out the door, a server can now think in terms of complete urls.
One of the issues with graphql is that it doesn't use HTTP semantics. Errors are 200 status with an error field in the body. Queries are POST /graphql for everything (ok, so they don't have to be, but once you've got anything in your system that needs to go over a POST request, everything else will).
This is problematic in any environment which expects those arguments to have been settled a decade ago and has built its monitoring around them. Ask me how I know.
But how does that cause problems? b/c the monitoring software cannot see the errors?
Well, even if it did, it presumably wouldn't be able to make sense of the error field anyway; so it either has support for graph-ql specifically, or cannot see the errors.
If the resolution of monitoring is literally is-200/not-200 a basic level of customisation should allow for "has error field" as a second error condition. Saying "expects those arguments to have been settled a decade ago" ignores that little in HTTP endpoints is settled, and building brittle software around these assumptions is the problem.
I once got into a heated argument about adding HTTP verbs. They said only the classic GET,POST,DELETE are RESTful and you should never define your own. I had to bust out Fieldings paper to show that only GET has special defined properties.
And that was with a Spring Boot contributor. Misconceptions abound.
Yea I’m fighting a redesign of a REST api where the designer has been out of touch with web dev since the 90s/early 00s. They want everything as GET or POST (for our purposes we don’t allow DELETE). Doing an update? Use POST. I tried to convince him PUT/PATCH should be used but nope it’s all POST.
Either, niether or both stances could be correct REST depending on the meaning you want to give the operation.
PUT replaces the entity or thing that has that url. If the entity didn't previously exist then it is created. A cache should be able to use the incoming entity and return it directly for a following GET to the same url (in the same way the entity returned by a GET might be cached). I don't think anyone would configure a cache to work like this any more - but that's the idea.
POST was the dynamic-web afterthought for anything that really didn't really fit into the website maintenance behaviour defined for GET, PUT or DELETE. You could send anything to an endpoint and it isn't cached. POST often gets used in REST to create an entity within a collection at the url, but really (in HTTP terms) anything goes. POST does allow for returning a cachable entity through use of a Location header.
PATCH came much later and its use in REST is debated. Originally it was intended to effciently update multiple text documents through use of a single patch (or diff) document in the body. From a HTTP/caching point of view it is effectively the same as a POST (i.e. this is not an entity so don't cache it). People use PATCH today because they want to partially update a larger entity, but HTTP and REST did not provide for this. How the body of a PATCH is to be interprited in REST is effectively undefined - its up to you, just as with POST.
Some prefer to do partial updates using PATCH for semantic reasons. Some like to use POST for syntactic ones. Some like to POST to a url extended to encode the part of the entity being changed (which is wierd but compatible with POST), and some wrongly do this with PUT.
Unless you can see functional issues (e.g. when a CDN somewhere sees a DELETE for a url and could assume it should now always return a 404), then it's probably best not to get too hung up on which verb to use.
These pointless arguments over HTTP semantics are one of the biggest problems with REST. Just use GET/POST for everything and stop thinking about which of these few verbs best fit your use-case. You'll be more productive.
1. an affirmative statement that HTTP semantics are mature and robust enough to express networked application communication
2. that using those semantics is better than not, when communicating over HTTP
This shouldn’t be controversial! Want GraphQL? Cool, ?foo[bar]=quux. Want a special data transport format? Cool, Content-Type: application/furby. Want a big blob of different content? Multipart has your back.
There’s nothing special about REST. Use the format! The only special thing is you have to… use it. POST / everything ain’t that. Sure it’s convenient for your custom format that doesn’t interop with anything. And then it’s a decade of articles about no one using common standards. Welp, this standard was here all along.