4 ms·

Having worked with SOAP/XML extensively at my past job I can say for web services I much prefer REST/JSON. JSON is much easier to work with and key value pairs

by wil421 7y ago

Having worked with SOAP/XML extensively at my past job I can say for web services I much prefer REST/JSON. JSON is much easier to work with and key value pairs make it much easier to get what you need. Parsing an XML tree can become a nightmare very quickly. > However, we’ve created another problem in the form of inconsistency: some user properties are represented as element attributes, others as child elements. Exactly. I’ve seen XML with element attributes and child elements all over the pace. No rhyme or reason for any of it. It’s especially bad in older systems. I pushed hard at my last job for the SOA team to build REST/JSON web services. Oracle sold them a product to bridge the gap and they got End Of Life announcements 6 months later! Glad I’m gone.

hagreet 7y ago
1. Why is parsing a tree which is encoded in JSON easier? 2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?
- LastMuel 7y ago
  The author makes a case for why it would matter: > XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements). Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes. So, you lose a bit of context in the conversion. Such as: `<Document text="true" />` Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know. Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
- wil421 7y ago
  It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON See this link on stack exchange[1]. [1] https://stackoverflow.com/questions/17604071/parse-xml-using-javascript https://stackoverflow.com/questions/17604071/parse-xml-using... > //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue; I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.
kgwxd 7y ago
I still work with SOAP occasionally. I'd never recommend anyone start a new project with it, but I've never had to manually parse anything. Did the framework you had to work with not provide decent XSD/Class code generation and serialization/deserialization tools?
- wil421 7y ago
  Yes and no. I worked with several middleware systems, a few disparate systems, and a couple very old systems. Right now I’m working on a few web service integrations with SerivceNow for Microsoft Teams, ticketing, and CMDB stuff, it has decent tools. When you are hacking systems together for large/old enterprises the water gets muddy fast.
thrower123 7y ago
When they did work, WSDLs were pretty slick. Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.
- wil421 7y ago
  Agreed WSDLs are the only thing I love about SOAP and they are missing from REST. Most tools can import a WSDL and generate the code and structure for you. Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes. I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.

by wil421 7y ago

hagreet 7y ago

1. Why is parsing a tree which is encoded in JSON easier? 2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?

LastMuel 7y ago
The author makes a case for why it would matter: > XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements). Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes. So, you lose a bit of context in the conversion. Such as: `<Document text="true" />` Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know. Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.
wil421 7y ago
It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON See this link on stack exchange[1]. [1] https://stackoverflow.com/questions/17604071/parse-xml-using-javascript https://stackoverflow.com/questions/17604071/parse-xml-using... > //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue; I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.

kgwxd 7y ago

I still work with SOAP occasionally. I'd never recommend anyone start a new project with it, but I've never had to manually parse anything. Did the framework you had to work with not provide decent XSD/Class code generation and serialization/deserialization tools?

wil421 7y ago
Yes and no. I worked with several middleware systems, a few disparate systems, and a couple very old systems. Right now I’m working on a few web service integrations with SerivceNow for Microsoft Teams, ticketing, and CMDB stuff, it has decent tools. When you are hacking systems together for large/old enterprises the water gets muddy fast.

thrower123 7y ago

When they did work, WSDLs were pretty slick. Technically, there are REST/JSON equivalents, but I don't see them actually used much in the wild - so much of the time with REST APIs you are stuck with whatever half-baked, out-of-date documentation that somebody may or may not have written, or just randomly poking at it through trial and error to discover how it works.

wil421 7y ago
Agreed WSDLs are the only thing I love about SOAP and they are missing from REST. Most tools can import a WSDL and generate the code and structure for you. Sometimes even getting a sample of the expected JSON format can be hard. If you’re not versioning you’re APIs you can break everything if the schema changes. I used to debate this with the SOA manager. Swagger looks ok but never dealt with it in production or saw it in the wild with our customers.