Apr 2, 2009 3:58 AM
To WSDL or to REST? That is the question.
An interesting question came up as a response to the Rich UI demonstrations during yesterday's EGL for IBM i Online User Group (Jon, we need a snappier name I think).
What is the difference between REST and SOAP/WSDL based services and how do you choose which one to use?
This is a large architectural area to cover and certainly couldn't be addressed in the limited time available on the call. I'm sure lots of you out there will have differing opinions on this (give 3 developers a problem and you'll get 7 solutions). I thought it would be interesting to kick off this discussion and see if we can all help enlighten each other and share some ideas.
My initial response to the question was that SOAP/WSDL services are "contract" type services whereas REST is more free-form. I'll try to expand on that a little and give you something to get your teeth into, there's nothing like someone else's opinion to get an IT geek frothing at the mouth
REST (Representational State Transfer) is actually an architectural pattern originally described by Roy Fielding. This paper can be a little dry in places but there are plenty of resources that explain it in simpler terms, it's worth seeking out a few and making sure you understand the principles.
We're interested in web or rather, HTTP implementations of REST. RESTful web services are all about manipulating uniquely addressable resources with a limited verb set. These resources represent the application and all its functionality. A client application does not necessarily need to know the whole of the resource set available to it as each resource will contain hyperlinks to associated resources. The client application will often not know the data structure being returned but will have code to interpret and act on it in an appropriate way.
This pattern results in some significant benefits for the providers and consumers of these services in terms of flexibility e.g. a client application can deal with a wide range of resource types and navigate resource sets with a smaller code base or a service provider can add new resources or modify existing ones more rapidly. I should say at this point I'm talking about the common implementations of REST that we're likely to come across, which have diverged from the pure, theoretical pattern as people take pragmatic approaches to developing the services.
WSDL (Web Services Description Language), in our case normally utilising SOAP (Simple Object Access Protocol) as
the communication protocol is a much more formal and standards based means of describing a web service which, rather than being resource-oriented, is based around ports supporting a discrete set of operations. These operations describe the input parameters they expect and the output parameters they will return (it's no accident that EGL interfaces feature heavily in the EGL Services documentation).
I like to think of these interfaces as my "contracts" with the outside world (now, we're getting somewhere with my original response). The operations represented by the WSDL are also a type of contract. You're saying to the consumer of the service that this is what I need you to do so I can return the correct information or invoke the right processes. This puts constraints on the service provider to make sure these contracts are maintained but gives assurance to the service consumer that as long as they respect the contract, the operations they're using will work OK (alright, should work OK, this is the IT world after all).
WSDL services also come with a whole raft of supporting standards covering such things as security, service registries, quality of service and so on, I'm sure there's someone, somewhere who knows what all these standards are, what they do and how to use them - not necessarily someone I want to meet for a beer or two though
So, that's the first part of the question, now comes the difficult job of trying to answer the second part.
First thing to say is that in general, RESTful services are far simpler to work with initially than WSDL services. Fortunately for us EGL has reduced that gap quite markedly. So the decision moves more towards similar choices we have when considering dynamically and statically typed languages. Do you need the protection, consistency and guarantees offered by WSDL or do you need the flexibility offered by REST?
I would normally consider WSDL for B2B type services, e.g. communications between an order fulfillment and a stock management system, or where I'm exposing business services to external users.
RESTful services fit nicely into the Web 2.0 world where things are changing rapidly, we want to deliver things quickly and have the scope to cope with sudden changes in the resources e.g. our Twitter client could be easily and quickly updated to cope if Twitter decided to add some cool new feature.
We're thinking here in terms of what's involved to cope with change; compare the work needed to update your order fulfillment system if there were a change to the stock management system against what it would take to update a
web application (include specifications, change management procedures, regression testing and deployment in those calculations).
Anyway, there are some of my thoughts on the subject (yes, all my own opinion, don't reflect my employer's opinion, facts may have been made up, characters not intentionally based on any real person living or dead etc, etc.).
Please feel free to correct any mistakes, offer your own opinions and criticise. I noticed on the developerWorks site that a more general discussion on this topic has been going on for some time and it's worth having a look there; or hit Google and post any interesting resources you find.
Andy
What is the difference between REST and SOAP/WSDL based services and how do you choose which one to use?
This is a large architectural area to cover and certainly couldn't be addressed in the limited time available on the call. I'm sure lots of you out there will have differing opinions on this (give 3 developers a problem and you'll get 7 solutions). I thought it would be interesting to kick off this discussion and see if we can all help enlighten each other and share some ideas.
My initial response to the question was that SOAP/WSDL services are "contract" type services whereas REST is more free-form. I'll try to expand on that a little and give you something to get your teeth into, there's nothing like someone else's opinion to get an IT geek frothing at the mouth
REST (Representational State Transfer) is actually an architectural pattern originally described by Roy Fielding. This paper can be a little dry in places but there are plenty of resources that explain it in simpler terms, it's worth seeking out a few and making sure you understand the principles.
We're interested in web or rather, HTTP implementations of REST. RESTful web services are all about manipulating uniquely addressable resources with a limited verb set. These resources represent the application and all its functionality. A client application does not necessarily need to know the whole of the resource set available to it as each resource will contain hyperlinks to associated resources. The client application will often not know the data structure being returned but will have code to interpret and act on it in an appropriate way.
This pattern results in some significant benefits for the providers and consumers of these services in terms of flexibility e.g. a client application can deal with a wide range of resource types and navigate resource sets with a smaller code base or a service provider can add new resources or modify existing ones more rapidly. I should say at this point I'm talking about the common implementations of REST that we're likely to come across, which have diverged from the pure, theoretical pattern as people take pragmatic approaches to developing the services.
WSDL (Web Services Description Language), in our case normally utilising SOAP (Simple Object Access Protocol) as
the communication protocol is a much more formal and standards based means of describing a web service which, rather than being resource-oriented, is based around ports supporting a discrete set of operations. These operations describe the input parameters they expect and the output parameters they will return (it's no accident that EGL interfaces feature heavily in the EGL Services documentation).
I like to think of these interfaces as my "contracts" with the outside world (now, we're getting somewhere with my original response). The operations represented by the WSDL are also a type of contract. You're saying to the consumer of the service that this is what I need you to do so I can return the correct information or invoke the right processes. This puts constraints on the service provider to make sure these contracts are maintained but gives assurance to the service consumer that as long as they respect the contract, the operations they're using will work OK (alright, should work OK, this is the IT world after all).
WSDL services also come with a whole raft of supporting standards covering such things as security, service registries, quality of service and so on, I'm sure there's someone, somewhere who knows what all these standards are, what they do and how to use them - not necessarily someone I want to meet for a beer or two though
So, that's the first part of the question, now comes the difficult job of trying to answer the second part.
First thing to say is that in general, RESTful services are far simpler to work with initially than WSDL services. Fortunately for us EGL has reduced that gap quite markedly. So the decision moves more towards similar choices we have when considering dynamically and statically typed languages. Do you need the protection, consistency and guarantees offered by WSDL or do you need the flexibility offered by REST?
I would normally consider WSDL for B2B type services, e.g. communications between an order fulfillment and a stock management system, or where I'm exposing business services to external users.
RESTful services fit nicely into the Web 2.0 world where things are changing rapidly, we want to deliver things quickly and have the scope to cope with sudden changes in the resources e.g. our Twitter client could be easily and quickly updated to cope if Twitter decided to add some cool new feature.
We're thinking here in terms of what's involved to cope with change; compare the work needed to update your order fulfillment system if there were a change to the stock management system against what it would take to update a
web application (include specifications, change management procedures, regression testing and deployment in those calculations).
Anyway, there are some of my thoughts on the subject (yes, all my own opinion, don't reflect my employer's opinion, facts may have been made up, characters not intentionally based on any real person living or dead etc, etc.).
Please feel free to correct any mistakes, offer your own opinions and criticise. I noticed on the developerWorks site that a more general discussion on this topic has been going on for some time and it's worth having a look there; or hit Google and post any interesting resources you find.
Andy
