

The only one I think is reasonable is GraphQL. But that isn’t rest, and HTTP is just one of the transport layers it supports.
For anything claiming to be RESTful, it’s a crime.
The only one I think is reasonable is GraphQL. But that isn’t rest, and HTTP is just one of the transport layers it supports.
For anything claiming to be RESTful, it’s a crime.
Two different concepts.
You’re talking about work slowing because of increased overhead from more people needing to communicate and make decisions.
The OP is talking about the"bus factor". How many people can leave the project unexpectedly and still have the project survive. E.g. if only one person has access to merge changes, the bus factor is 1 regardless of how many people actively contribute.
(another pet peeve of mine is “rest” APIs that use 200 response codes for everything)
Yup, also some APIs use GET for everything. It’s a pain. And it means that filtering by verb only helps if you’re intimately familiar with the API. And even then, only if you keep up with changes as they happen. So really, only if you’re developing the API yourself.
I don’t know how dead it is, but it’s pretty straightforward to set up your own gateway (public or private). Even if you don’t have a tech background, there’s the “IPFS Desktop” app that stands up the IPFS service locally.