Hacker News Reader

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.

View on HN

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.

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.

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.

Reply on news.ycombinator.com