[darrelmiller]

The one distinction that I think is worth making is that OpenAPI describes HTTP APIs using the semantics of HTTP. Corba and SOAP attempted to be protocol independent. That's much harder to do well. Another good aspect of OpenAPI is that most people who are using it, are starting towards using the definition as the primary design artifact and then letting tooling work on that. Almost no-one designed WSDL or IDL by hand. Focusing on an OpenAPI as a design contract helps developers produce solutions that are more independent of tooling. And that's a good thing.

[MichaelGG]

There's nothing wrong with just "tunneling" SOAP or anything else over HTTP POST. Tons of APIs do this and work just fine.

Now maybe it's easier on clients when you can just curl -XDELETE something but I'm not sure it's that big of a difference in the end. Especially if you have auto-gen'd client code.

[paulddraper]

The problem is that you abandon a bunch of existing architecture and middleware: an extremely rich caching API, content negotiation, proxy info, authentication.

I can trivially set an HTTP load balancer and log status codes. Can't say the same for SOAP.

[darrelmiller]

It makes it hard to take advantage of HTTP caches. There is also some redundancy because SOAP has headers and HTTP has headers. Which to use? It also is handy to be able to make idempotent requests, especially over flakey networks.

[MichaelGG]

HTTP caching is a good benefit. But you can get it just by using GET and shoving the body in the querystring.

Headers: Use the SOAP ones, you're just tunneling SOAP messages.

Idempotentcy requires the app to implement it that way. HTTP doesn't really help there.