[nostalgeek]

It seems to me that REST "was never meant to solve web developers problems" at first place and that dissertation wasn't addressed to them. I'm glad we are getting out of REST. Devs need protocols and specifications, not vague architectural ideas that leads to "you're doing it wrong" blog posts. There is no "you're doing it wrong" with GraphQL, or SOAP, or JSON-RPC, you either follow the spec or you don't.

[bborud]

> Devs need protocols and specifications, not vague > architectural ideas that leads to "you're doing it wrong" > blog posts.

This is precisely it. If an integration mechanism can't be implemented as a clear and uncomplicated library that strongly encourages correct use by making it the path of least resistance, it probably isn't any good.

(And note that I said "library" rather than "framework". This is important as libraries are more like a thin layer of glue while framework is more like a metastasising cancer)

Most of the time, REST, strictly speaking, demands too much attention even for relatively simple stuff, and therefore is not a good integration technology. However, some adaptations of REST are.

The one thing that is a bit sad is that there is some nomenclature confusion. These days a REST API doesn't refer to Fielding's vision, but a more practical adaptation of the mechanical bits of it.

[organsnyder]

OpenAPI (née Swagger) helps a lot with this. While I'm sure that many purists would argue that you're not really doing REST if you have an OpenAPI contract, it certainly helps a lot with making APIs more usable to consumers.

[vertere]

Both well-defined protocols and vaguer design/architectural principles have their place. But is it a great idea to take a bunch of such principles and bundle them up under a (confusing) name? Perhaps not.

It seems to me that the initial popularity of "REST" was largely because it wasn't SOAP (and didn't have to be XML), but it was still a name you could give what you were doing that made it sound like you were following some sort of standard.

[silverbax88]

I had zero issues with SOAP. I had zero issues with REST, although I couldn't quite understand the proposed benefit. When people started moving to JSON, I thought, okay, this is literally taking everything that already works and just doing it in an even more complicated way.

It's not hard, but I see very few differences between them. SOAP is easier to read/edit, JSON has less overhead/data, and REST...well, nobody could decide what REST was, so they just made it up or ignored it.

[mwcampbell]

> I had zero issues with SOAP.

Just curious, what programming language(s) did you use to provide and/or consume SOAP APIs?

[cpburns2009]

I'm not the OP but I've used Python with the suds library to consume SOAP APIs. I haven't had any problems with it other than companies deprecating their SOAP APIs just to reimplement exactly the same thing with JSON.

[mwcampbell]

Ah, OK. I don't think suds existed when I first tried to access a SOAP API from Python in 2004. If it did exist, it was certainly obscure.

Perhaps my own experience trying to use SOAP can shed some light on why REST prevailed. In 2004, I tried to use the PayPal mass payment API from a Python application (in the now-defunct Quixote web framework). As I recall, I found one Python SOAP client library, but for some reason, I couldn't use it to access the PayPal API. It was all just so complicated. In desperation, I ended up writing a small service (micro-service?) to access the PayPal API using the official PayPal Java SDK. That service used Jython, because I just couldn't stand Java's verbosity. The main application communicated with the service using XML-RPC.

Compared to SOAP, when I discovered REST, it seemed refreshingly simple, built for the Web rather than awkwardly abusing HTTP as a transport for an over-complicated RPC protocol.

[silverbax88]

Quite a few over the years. .NET, Java mostly in the early days. Sometimes I would just write a parser in whatever language I needed.

[noir_lord]

I just use this https://labs.omniti.com/labs/jsend and typed it up via TS.

It makes for nice code.

    Promise<JSendApiResponse>

With the benefit of HTTP level stuff not been mapped onto application level stuff.

I like KISS with this kind of thing and if you need a more complex solution it handles that as a starting point.

[indexerror]

You can do this with Axios too:

  interface IResponse {
    foo: string
  }
  
  async function doSomething() {
    const reponse: AxiosResponse<IResponse> = await Api.call()
    ...
    // or you can use AxiosPromise<IResponse> without the await
  }

[mschaef]

> There is no "you're doing it wrong" with GraphQL, or SOAP, or JSON-RPC,

Where there's a will, there's a way to 'do it wrong'. It's amazing the kinds of messes people can (or are forced to) dream up in this world... even if they're ostensibly playing by rules that aim to make messes 'impossible'.