WebService? XML? SOAP? REST? What?
Look! Up in the sky! Is it a bird? Is it a plane? No! It's XML! Er, no -- its SOAP! No, scratch that - its --- its --- well, dang-it! Its Something, ain't it?
Interesting because what with all the so-called web "API's" put out by everybody and their little brother these days, its getting harder and harder to figure out what you are dealing with. if it's XML, did it come from a WebService? or is it just a resultset in XML format? Who the hell knows, right? Yahoo's new Web Search API's get called with REST - and return either RSS or some sort of XML resultset. There's XSD schemas for those, but no SOAP -- yikes!
This all became even more clear this evening when I was answering a post on the C# MS Newsgroup about how to deal with something that was obviously an XML Document representing a "result" object, but with no SOAP wrapper. The poster was asking essentially, "what's the best way to deal with this?".
Not long after, I ran into Simon Guest's blog where he has fortuitously laid out in black and white Arial 11 point type EXACTLY what he thinks are the determinants of what is a WebService. I reproduce them here:
1. Uses WSDL. A Web Service should expose its service contract using WSDL. If it can’t give you a WSDL document, it’s probably just XML over HTTP
2. Uses SOAP. All messages sent from and received by the Web Service must use SOAP formatting. If it’s not using SOAP it’s probably just XML over HTTP
3. Uses XSD. All data types in the SOAP payload must be XSD compliant. No platform native types are allowed. If it’s not using XSD it’s probably just XML over HTTP
4. Uses XML. The underlying messages should of course be formatted using XML.
5. No Arbitrary Binary Data. The message payload should 7 bit ASCII and should contain no embedded binary blobs. Any binary data passed over a Web Service should be sent using either SwA, DIME or MTOM (preferably MTOM).
6. Transport is likely to be HTTP. Although not a requirement, the majority of Web Services today use HTTP as the transport. Compliant Web Services should definitely work over HTTP.
7. Discovery can be through UDDI. Again although not a requirement, it should be possible to host the Web Service endpoint using UDDI.
8. Agreed Versions of Specifications. The versions of the above specifications (WSDL, SOAP, XSD, XML, HTTP, UDDI) should be in line with the latest version of the WS-I Basic Profile (http://www.ws-i.org) – to ensure Web Service compliance between vendors.
9. Operations should be Document Style. Operations to/from a Web Service should be Document/Message Style (e.g. SendOrder(order o)). RPC style should be avoided (e.g. SetOrderLine1(orderId id)).
10. Should be compliant with WS-*. Compliant Web Services should be able to accept WS-* payloads and extensions for Security, Reliability and Transactions (although not all stacks today support these yet).
Now, you can get all huffy and make excuses and attempt to eliminate some of the above based on this, that or the other. But the point is, this is the first time I have seen anybody possessing an above room-temperature IQ and some credentials actually lay it out and put a number in front of each Commandment.
The first 4 "Commandments" are so ubiquitous, and the standards so well set and agreed on, that they are really a no-brainer at this late stage of the game. Butter my butt and call me a biscuit, Mabel - if it don't offer WSDL, use SOAP, support XSD Schema, and come over as well-formed XML, it ain't a Webservice!
Nice, Simon! If I can find the first six, I'll be happy! One of the things I like about standards is -- you know there won't be any Filibusters. You either dig the standard, or you don't!
Interesting because what with all the so-called web "API's" put out by everybody and their little brother these days, its getting harder and harder to figure out what you are dealing with. if it's XML, did it come from a WebService? or is it just a resultset in XML format? Who the hell knows, right? Yahoo's new Web Search API's get called with REST - and return either RSS or some sort of XML resultset. There's XSD schemas for those, but no SOAP -- yikes!
This all became even more clear this evening when I was answering a post on the C# MS Newsgroup about how to deal with something that was obviously an XML Document representing a "result" object, but with no SOAP wrapper. The poster was asking essentially, "what's the best way to deal with this?".
Not long after, I ran into Simon Guest's blog where he has fortuitously laid out in black and white Arial 11 point type EXACTLY what he thinks are the determinants of what is a WebService. I reproduce them here:
1. Uses WSDL. A Web Service should expose its service contract using WSDL. If it can’t give you a WSDL document, it’s probably just XML over HTTP
2. Uses SOAP. All messages sent from and received by the Web Service must use SOAP formatting. If it’s not using SOAP it’s probably just XML over HTTP
3. Uses XSD. All data types in the SOAP payload must be XSD compliant. No platform native types are allowed. If it’s not using XSD it’s probably just XML over HTTP
4. Uses XML. The underlying messages should of course be formatted using XML.
5. No Arbitrary Binary Data. The message payload should 7 bit ASCII and should contain no embedded binary blobs. Any binary data passed over a Web Service should be sent using either SwA, DIME or MTOM (preferably MTOM).
6. Transport is likely to be HTTP. Although not a requirement, the majority of Web Services today use HTTP as the transport. Compliant Web Services should definitely work over HTTP.
7. Discovery can be through UDDI. Again although not a requirement, it should be possible to host the Web Service endpoint using UDDI.
8. Agreed Versions of Specifications. The versions of the above specifications (WSDL, SOAP, XSD, XML, HTTP, UDDI) should be in line with the latest version of the WS-I Basic Profile (http://www.ws-i.org) – to ensure Web Service compliance between vendors.
9. Operations should be Document Style. Operations to/from a Web Service should be Document/Message Style (e.g. SendOrder(order o)). RPC style should be avoided (e.g. SetOrderLine1(orderId id)).
10. Should be compliant with WS-*. Compliant Web Services should be able to accept WS-* payloads and extensions for Security, Reliability and Transactions (although not all stacks today support these yet).
Now, you can get all huffy and make excuses and attempt to eliminate some of the above based on this, that or the other. But the point is, this is the first time I have seen anybody possessing an above room-temperature IQ and some credentials actually lay it out and put a number in front of each Commandment.
The first 4 "Commandments" are so ubiquitous, and the standards so well set and agreed on, that they are really a no-brainer at this late stage of the game. Butter my butt and call me a biscuit, Mabel - if it don't offer WSDL, use SOAP, support XSD Schema, and come over as well-formed XML, it ain't a Webservice!
Nice, Simon! If I can find the first six, I'll be happy! One of the things I like about standards is -- you know there won't be any Filibusters. You either dig the standard, or you don't!
Comments
Post a Comment