Reputation: 15551
At present, we have a number of web services where when we send data to them, we send it as a string which is an XML block and the web service parses and does some work.
Similarly, when we need data from a web service, we are returning a string which is again an XML block which the client application parses.
Are there disadvantages in doing it this way. Also should we be returning types that get serialized to xml?
JD
Upvotes: 0
Views: 1212
Reputation: 103
Unlike SOAP-based web services, there is no "official" standard for RESTful web APIs. This is because REST is an architectural style, while SOAP is a protocol. Even though REST is not a standard per se, most RESTful implementations make use of standards such as HTTP, URI, JSON, and XML. Check detail here
Upvotes: 0
Reputation: 654
I've done the xml in/out method before for web services as. When I did it was to try out the "covenant" model of parameter passing. It worked out pretty well overall, made things fairly easy to implement and revision.
The implementaiton that I followed was to create the schema for my input/output xml, and then use xsd to generate classes for serialization. So within my web service I just worked with strongly typed objects and serialized to/from xml to handle the actual request and response.
Some pros
Some cons
Upvotes: 1
Reputation: 1039398
A couple of disadvantages:
Upvotes: 1
Reputation: 12092
If you send XML as a string and return it as a string, you may as well use REST.
The whole point of webservices is that the XML serialization and deserialization (marshalling/unmarshalling) is taken care of for you, so simply pass complex types around, or a Request object as input and return a Response object.
And you get strong typing without any effort.
Upvotes: 2
Reputation: 9160
I prefer the serialized method when using this type of webservice. However, you might look at WCF since it offers many advantages over an ASMX web service.
Upvotes: 1