REST is an anti-standard. It doesn't tell you what to do, it just gives you some guidelines of sorts. And honestly, you don't even have to follow them - the spirit of REST is in simple JSON + HTTP-based operations.
POST /accounts/ {username, contact_email, password} -> {account_id}
POST /accounts/:account_id/subscriptions/ {subscription_type} -> {subscription_id}
POST /accounts/:account_id/send_activation_reminder_email/ -> {}
DELETE /accounts/:account_id/subscriptions/:subscription_id/ {reason, immediate} -> {}
GET /accounts/:account_id/ -> {full data tree}
...Or an unending number of other interpretations. You can, for example, flatten the tree and put `/subscriptions/` at the root. Doesn't matter. It isn't that ridiculously hard to understand or formulate.
And if you want, you can make everything perfectly RESTful and make everything a resource. Kubernetes and its API objects concept are great examples. Deploying services with POST/PATCH/PUT? Just add some layers of abstraction.
Having REST bindings for many languages is not a ridiculous thing to do either. If your API is huge, autogenerate it somehow. Swagger/OpenAPI exists. Or, maybe don't make bindings at all. If I wanted to write payment handling code for Stripe, I'd feel no hesitation doing it by making the HTTP requests directly. It's not hard or scary. Them having rich, quality libraries for many languages is a marketing decision, and a damn good one in my opinion. It does things that no cross-language abstraction layer could to make life as simple as possible.
Honestly, people can do whatever they want, but I genuinely do not get why REST-based services are so bad. Honestly, if anything is difficult nowadays, it's authentication. I'm a big fan of OAuth2, but there's a thing that isn't fun to write client libraries for.
(I have. The problem isn't that it's complicated; the problem is that nobody implements it right. Google's OIDC implementation has all kinds of bugs. Losing scopes on refresh is incredibly annoying.)
and when someone joins the team and raises endless arguments with you about how what is already working isn't REST, because their interpretation is different, you have problems.
and when you have a client that insists that you're not following REST conventions because your endpoints take POST for everything and don't take actual PUT commands, and they are not going to retool their interpretation of REST to match yours, you have problems.
These problems would exist anyway - interacting with other people usually brings some problems with it - but putting things under this banner of REST implies that there is some 'right' way of doing things which contributes to the interaction problems.
Just acknowledging "hey, this could have been done 4 ways, this is the way that was chosen, deal with it" - regardless of whether the REST acronym is involved or not - should be the way to go, but an implied 'standard' creates more hurdles.
I could say the exact same thing about RPC. API design is difficult, largely in part because programmer types often refuse to acknowledge the "design" part. REST actually improves this by providing a sane set of ideas to base your web API design off of. It only makes it worse if you want it to.
REST has plenty of nice advantages people ignore too, like for example, often with REST APIs, ACL and authentication can be handled much easier because you can use URLs as a primitive for permissions.
REST is an anti-standard. It doesn't tell you what to do, it just gives you some guidelines of sorts. And honestly, you don't even have to follow them - the spirit of REST is in simple JSON + HTTP-based operations.
As an example, this?
Could be this: ...Or an unending number of other interpretations. You can, for example, flatten the tree and put `/subscriptions/` at the root. Doesn't matter. It isn't that ridiculously hard to understand or formulate.And if you want, you can make everything perfectly RESTful and make everything a resource. Kubernetes and its API objects concept are great examples. Deploying services with POST/PATCH/PUT? Just add some layers of abstraction.
Having REST bindings for many languages is not a ridiculous thing to do either. If your API is huge, autogenerate it somehow. Swagger/OpenAPI exists. Or, maybe don't make bindings at all. If I wanted to write payment handling code for Stripe, I'd feel no hesitation doing it by making the HTTP requests directly. It's not hard or scary. Them having rich, quality libraries for many languages is a marketing decision, and a damn good one in my opinion. It does things that no cross-language abstraction layer could to make life as simple as possible.
Honestly, people can do whatever they want, but I genuinely do not get why REST-based services are so bad. Honestly, if anything is difficult nowadays, it's authentication. I'm a big fan of OAuth2, but there's a thing that isn't fun to write client libraries for.
(I have. The problem isn't that it's complicated; the problem is that nobody implements it right. Google's OIDC implementation has all kinds of bugs. Losing scopes on refresh is incredibly annoying.)