views:

163

answers:

2

I work a lot with 3rd party web services. The first thing I look for is if they provide a WSDL that I can easily add into Visual Studio and start immediately using the auto generated proxy class that VS creates based off the WSDL and obviously I am able to start coding quickely and start using whatever 3rd party API.

So for example PayPal offers 2 flavors of their API. One via Name Value Pairs and the other SOAP which exposes a WSDL that I can use in my .NET projects and off I go.

So can I assume the following in regards to terminology here?

  1. NVP does not provide a WSDL (It's done by querystring name value pairs passed in the HTTPRequest)
  2. SOAP web services may or may not provide a WSDL at all times for you to incorporate into your projects in order to consume
  3. REST is just a naming onvention that can be applied to NVP -or- SOAP/WSDL type of APIs
  4. Is it called an API or SDK? I always refer to a service that I'm accessing and making API calls to an "API" but for some reason my boss calls it an SDK which doesn't make sense to me...API is what I see most out there

I'm not quite sure my statements are 100% correct and need to clear this up.

+1  A: 

All SOAP web services should provide a WSDL. They need not provide it online, through a URL. It's possible that the web service vendor will send you a WSDL via email or some other channel. The important thing is that there should be a WSDL to describe the service.

"NVP" is just something that PayPal and maybe a few others are using. It's not some kind of standard.

REST is separate architectural style. See SOAP or REST.

John Saunders
Well, NVP does not have a WSDL available.
CoffeeAddict
and NVP is not using SOAP, it's using querystring params instead of SOAP / WSDL
CoffeeAddict
Am I wrong?? Please do correct me if I'm wrong...but that's been my experience. I just cannot verify if the terminology I state is correct but that's what I see out there when using both types of APIs
CoffeeAddict
I have not seen "NVP" as a general architectural style for web services. I think you may be over-generalizing - what you call "NVP" may be used by a small number of services, but not by enough services industry-wide for the industry to treat it as an architectural style, as is done for RPC (SOAP) and REST.
John Saunders
Thanks John. I went with the other guy's response this time..I got more in terms of what I was looking for but thanks for your time.
CoffeeAddict
+4  A: 
  1. NVP does not provide a WSDL (It's done by querystring name value pairs passed in the HTTPRequest)

What PayPal calls Name-Value-Pairs is not a standard. However, they are not the only ones using it (it seems). It is basically sending parameters as pairs of names and values (obviously) which is very easy to deal with programmatically because HTML forms do the same thing, so by sending NVP you are simulating a web form and the server side programming is the same.

In short, it is easier to call it NVP than to say: please use application/x-www-form-urlencoded.

  1. SOAP web services may or may not provide a WSDL at all times for you to incorporate into your projects in order to consume

In theory, yes. SOAP as a protocol does not enforce the use of WSDL for definition/description. It only describes the messages between clients and servers (and/or intermediaries). Realistically, however the concept of SOAP web services usually means web services that are described using WSDL and that use SOAP for message exchange. Almost all available software (.Net, Java, and others like gSOAP C/C++) define web services through WSDL. Tools are available to convert predefined classes into WSDL and vice versa, SOAP is usually handled by the library support.

In short, the way you consume web services by generating classes from WSDL is the standard one. While SOAP defines the messages exchanged, if there is no definition of the service - in WSDL - it is not a web service as there is no service contract.

  1. REST is just a naming onvention that can be applied to NVP -or- SOAP/WSDL type of APIs

REST is certainly not a naming convention, it is an architectural style, built largely around the concept of resources and hyperlinks to them. There are good explanations around, but you can largely identify it by the style: you use a small set of verbs (usually HTTP: GET, POST, PUT, DELETE or part of them) to achieve actions you want on resources. An easy way to identify those is:

  1. Addresses denote resources, so rather than having actions like Sale, Authorisation and Order being sent as part of the request you will deal with different addresses looking like http://www.example.org/Sales/sale-015 and http://www.example.org/orders/1337 which you can access using GET or delete using DELETE or modify using PUT or POST as appropriate.

  2. The responses for REST requests usually contain relevant links which you can use for potential next actions. So a response message for a Sale may contain links enabling you to confirm the sale.

REST gives the client and server more latitude in modification if implemented correctly. By contrast, SOAP web services clients and servers must stick to the WSDL contract defined to interoperate.

  1. Is it called an API or SDK? I always refer to a service that I'm accessing and making API calls to an "API" but for some reason my boss calls it an SDK which doesn't make sense to me...API is what I see most out there

An API (application programming interface) is a defined list of functions which are accessible from outside and thus define an interface. An SDK (software development kit) is a group of software tools and libraries you would use to develop a software. So if you download executable code that is SDK; if it is documentation that is API.

Paypal provides an API. By constrast, to develop software for the iPhone (just to pick an example) you would have to download an iPhone SDK from Apple.

Muhammad Alkarouri
thanks. I think it's weird that some don't provide SOAP and just application/x-www-form-urlencoded
CoffeeAddict
Facebook provides no WSDL and I just don't get that. Why wouldn't you support basically the main web service type that most everyone wants to use?
CoffeeAddict
Basically, they are different approaches to web services. If you take an API like [Amazon S3](http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAPI.html) which has both REST and SOAP APIs, it is not more difficult to use REST than SOAP. The WSDL helps, but you still have to read the documentation. In the past, Amazon have provided SOAP and REST API to their services and had more than 80% of developers use the REST one. So, not most everyone wants to use SOAP.
Muhammad Alkarouri
REST vs SOAP is a full blown discussion that is available elsewhere. SOAP tends to be liked by those who use IDEs (like Visual Studio) and static languages. In my experience it lulls you in a false sense of interoperability, since WSDL contracts are interpreted by different software in slightly different ways. I had to work with Apache Axis (Java), .Net (C#), C (gSOAP), and various Python libraries, and recently with a software called Pipeline Pilot used in chemoinformatics. And let me tell you, it is not as easy as the theory says.
Muhammad Alkarouri
A basic difference: in SOAP web services anything goes, so you have to write a contract (WSDL). Many other web services have a standard contract not a server supplied one: most blogs export xml-api services for publishing; web feeds are published using Atom (or RSS); and REST services usually use HTTP as their contract.It is more useful and easier to use a contract that is known by everybody than to create a new one for every service.I should probably stop here. If you are still interested, you can browse the relevant questions. Or ask.
Muhammad Alkarouri