Comment by viraptor | Hacker News Reader

Comment by viraptor | Hacker News Reader

Parent Full thread

Just playing a devil's advocate here a little bit, but soap doesn't really require that much. For example for .net, you just run wsdl on some url and it generates the interface code for you.

Also the complexity is needed when your size goes up. Even verifying that the requests make sense is easier with schemas. Right now there is some project for json-schema going on, but it's not crazy popular yet. SOAP can be self-documenting too with its own structure mappings, type restrictions, etc. etc.

Don't you think it's only delaying the fact you'll have to reimplement the same stuff at some point yourself (since json based rest simply doesn't provide them out of the box)? (yeah - I know rest is protocol independent, so you can have xml and schemas too, but majority of "rest" services just throw some json and hope it sticks ;) - too bad if it changes between versions)

And how many internet startups are using VisualStudio.NET? (non-0, to be sure, but they are the outliers)

And pay attention to the cross-stack arguments, to say nothing of the cross version differences.

You remind me of this guy on stackoverflow: http://stackoverflow.com/users/76337/john-saunders -- M.S. kool-aid, yummie!

I am still waiting for any feedback (not from John, just in general) on this question: http://stackoverflow.com/questions/2194316/good-book-for-wri...

I guess anybody who know how to do these would be out pillaging and plundering corporate "america", not writing books :-)

First of all, the fact that you need such a code generator for the interface is a smell, not a good thing. To consume a REST service, you just need an HTTP client, possibly some authentication hashing, a url, and parameters and a json parser. You then get a hash.

The Web services I've used tend not to be super complicated. A handful of api calls tend to be used.

There's also versioning, which is handled well with a good url structure.

Also, the schema problem is more of a JSON vs XML issue. I personally use JSON because it's simpler for flatter data graphs. I also use JSON schema btw. XML does have the advantage of xpath (or css selectors) too.

But even in the REST + XML case, the XML is simpler than the XML + SOAP case.

Which brings up Content-Type. Rest can serve pretty much any content type in a way that's readable by almost any web-enabled client. Not so with SOAP. You need to have more software.

Basically, I can add these features on an as needed basis. REST is easier to work with right now and I probably will not need all of the features of SOAP. That's the gist of why it's less popular now.

Reply on news.ycombinator.com