REST is the new SOAP

I'm remaining firmly unconvinced.

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?

    createAccount(username, contact_email, password) -> account_id
    addSubscription(account_id, subscription_type) -> subscription_id
    sendActivationReminderEmail(account_id) -> null
    cancelSubscription(subscription_id, reason, immediate=True) -> null
    getAccountDetails(account_id) -> {full data tree}

Could be this:

    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.)

Surprised to have scrolled this far and not see one mention of GraphQL. It has a discoverable, schema based design, strongly typed. It segments requests into three types, queries, mutations, and subscriptions. Queries are simple data fetching. Mutations can be treated like RPC calls. Subscriptions are for long lived connections to receive live updates for data queries. I think it fixes a lot of problems with REST. I think it works extremely well with microservice architecture.

We've asked you many times to please comment civilly and substantively, and yet you've continued to repeatedly violate the guidelines, so we've banned the account. We're happy to unban accounts if you email us at hn@ycombinator.com and we believe you'll start following the guidelines.

https://news.ycombinator.com/newsguidelines.html

> Why is REST so popular?

REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer.

The main cause you don't need REST limitations to achieve same goals.

OP has strong opinion about why we need to reimplement rpc over http every time for every application and write clients for every popular platform to be able to consume it.

Every time I use REST from any google cloud api, my hair is moving and you definitely will have nightmares if you look into their python client code.

btw SOAP was supposed to be "xmprpc standardized"

I remember well the meeting when things started to go off track...