3 ms·

The fact that SOAP is not reasonably supported in a browser was a huge reason it fell down. When SOAP first came on the scene, complicated AJAX based applicati

The fact that SOAP is not reasonably supported in a browser was a huge reason it fell down. When SOAP first came on the scene, complicated AJAX based applications were not typical. But as more and more JSON/HTTP APIs emerged in conjunction with browsers becoming more powerful and rich apps build built in them, the meaninglessness & complexity of SOAP grew. Also, another major issue with SOAP is that most all of the popular tools would generate classes based on a WSDL. This creates a toolchain issue that is readily solved for someone experienced, but can really suck if you are new to the idea of generated code working it's way into your project. Much worse was the scenario of WSDL versioning in conjunction with these tools that generated classes. If the API never broke backwards compatibility, you should be OK and can just use the newer class representations, counting on the service and tools to deal with null fields appropriately (not always true unfortunately). But if version bumps of an API/WSDL broke backwards compatibility... then you had to have separate class hierarchies for different versions of the WSDL; what an intense headache. Contrast that to web REST APIs; without a formal schema and a lack of class-centric tooling, client libraries would often let the author stuff in the params themselves and let the serializer stuff in the body based on the params; so yes your API is not as formal, but this isn't a big issue but offers infinite flexibility in dealing with one-off versioning issues or interop issues. As someone else mentioned, some platforms couldn't interop with others (differences as it related to simply stuff like nullable fields or primitives existed all over; total nightmare), and some features of WSDLs didn't translate well to certain languages. A great WSDL author would know to make their WSDL as simple as possible, because they had spent time working with various language toolchains and new the limitations out there, but that's asking way too much and not realistic for someone to have to spend all their time trying to understand all the ways someone in language XYZ might use their WSDL.

PantaloonFlames 12y ago
Turns out the "definition language" (WSDL) and the presumption that it would be simpler to deal with than just showing people the messages that needed to be placed on the wire... was the broken assumption. We wanted automagic seriaization and de-serialization and we wanted every language-based construct (linked lists, arrays of structures that contain arrays) to be supported. Different tool vendors built that differently, hence the interop problems. In REST/JSON, we don't have an IDL. We don't have a JSON Schema (yet! thank god) We generate human-readable documentation containing examples, for the definition. And developers build to those examples. There's nothing - no runtime or static tool - that gets in the way of developers serializing their data into JSON, the way they need to.
twic 12y ago
My observation of the rise of JSON/HTTP was that it was a thing happening in the dynamic language communities, and that only came into the Java world when the battle was already over. I suspect the dynamic language communities preferred JSON/HTTP so strongly because it was so much easier to use: they didn't have big corporate backers releasing SOAP tooling, but it's trivial to parse JSON straight into structures that are more or less native to the language (arrays of objects in JavaScript, lists of dicts in Python, arrays of hashes in Ruby). Java did have heavy-duty SOAP tooling, and didn't (and doesn't) have a natural way to represent JSON's objects, so it was much less of a win there.
- hayksaakian 12y ago
  Not sure what you mean. What about https://github.com/douglascrockford/JSON-java https://github.com/douglascrockford/JSON-java ?
  - twic 12y ago
    Given the JSON string: {"cities": [{"name": "London"}, {"name": "New York"}]} Parsed into a variable called 'root' with either 'new JSONObject(...)' or 'json.loads(...)', compare: root.getJSONArray("cities").getJSONObject(0).getString("name"); To: root['cities'][0]['name'] The Python version is the sort of thing you find yourself writing in Python anyway (at least, if you write tabloid-level Python the way i do); it's reasonably idiomatic. The Java version is cumbersome and feels very un-Javaish. Bear in mind that with SOAP, in Java, by that point you would have mangled the data into realistic-looking objects, and would write something like: root.getCities().get(0).getName();

PantaloonFlames 12y ago

Turns out the "definition language" (WSDL) and the presumption that it would be simpler to deal with than just showing people the messages that needed to be placed on the wire... was the broken assumption. We wanted automagic seriaization and de-serialization and we wanted every language-based construct (linked lists, arrays of structures that contain arrays) to be supported. Different tool vendors built that differently, hence the interop problems. In REST/JSON, we don't have an IDL. We don't have a JSON Schema (yet! thank god) We generate human-readable documentation containing examples, for the definition. And developers build to those examples. There's nothing - no runtime or static tool - that gets in the way of developers serializing their data into JSON, the way they need to.

twic 12y ago

My observation of the rise of JSON/HTTP was that it was a thing happening in the dynamic language communities, and that only came into the Java world when the battle was already over. I suspect the dynamic language communities preferred JSON/HTTP so strongly because it was so much easier to use: they didn't have big corporate backers releasing SOAP tooling, but it's trivial to parse JSON straight into structures that are more or less native to the language (arrays of objects in JavaScript, lists of dicts in Python, arrays of hashes in Ruby). Java did have heavy-duty SOAP tooling, and didn't (and doesn't) have a natural way to represent JSON's objects, so it was much less of a win there.

hayksaakian 12y ago
Not sure what you mean. What about https://github.com/douglascrockford/JSON-java https://github.com/douglascrockford/JSON-java ?
- twic 12y ago
  Given the JSON string: {"cities": [{"name": "London"}, {"name": "New York"}]} Parsed into a variable called 'root' with either 'new JSONObject(...)' or 'json.loads(...)', compare: root.getJSONArray("cities").getJSONObject(0).getString("name"); To: root['cities'][0]['name'] The Python version is the sort of thing you find yourself writing in Python anyway (at least, if you write tabloid-level Python the way i do); it's reasonably idiomatic. The Java version is cumbersome and feels very un-Javaish. Bear in mind that with SOAP, in Java, by that point you would have mangled the data into realistic-looking objects, and would write something like: root.getCities().get(0).getName();