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?
- NVP does not provide a WSDL (It’s done by querystring name value pairs passed in the HTTPRequest)
- SOAP web services may or may not provide a WSDL at all times for you to incorporate into your projects in order to consume
- REST is just a naming onvention that can be applied to NVP -or- SOAP/WSDL type of APIs
- 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.
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.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.
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:
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.
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.
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.