0

Given current maturity of REST frameworks/APIs, which should be the better option for a new SOA project - soap or rest?

PS - Excuse me for a being a noob, let me know if asking a wrong question!

Raúl
  • 1,542
  • 4
  • 24
  • 37
  • possible duplicate of [SOAP or REST for Web Services?](http://stackoverflow.com/questions/76595/soap-or-rest-for-web-services) – John Saunders May 19 '15 at 14:47
  • Which features of SOA are important to you? For instance, REST services are not self-describing. This makes certain scenarios more difficult with REST. – John Saunders May 19 '15 at 14:48
  • It should support a big enterprise application, communication with existing systems; need to be statefull, with security involved. Thank you. – Raúl May 19 '15 at 14:58
  • 1
    That pretty much implies SOAP, as the best you can do with most RESTful services is HTTPS. – John Saunders May 19 '15 at 15:02

2 Answers2

0

This is a bit up in the air. Now I am generally a bit biased towards REST, but REST and SOAP are two different animals. REST is more of an architecture style where as SOAP is a delineated protocol. Having said that, I have definitely written many SOAP interfaces.

One thing that I would like to note is that with REST you are not limited on the representation of the data, so it could be in XML, JSON, YAML, etc. As a result your data can be much more lightweight. However, for SOAP you must use XML. One thing to definitely take into account though is how this service is going to be consumed.

Generally, if your service is going to be used by a Mobile Device(Android,iOS, Windows Phone) there are a lot more frameworks around REST, so it would be wise to utilize those existing frameworks. If you have older large corporations connecting to this they are likely going to have existing SOAP implementations so they are going to be more comfortable with accessing SOAP services.

I would say however that providing both is not really that far of a stretch. If you have a service at /api/v1/customers << this could be your rest URL and for the SOAP protocol use /api/v1/soap/customers/*. As long as your business logic, if there is any is encapsulated into different functions, then both the SOAP and REST implementations can call it.

I hope that this is helpful, but with many questions around technology, don't try to force your use case fit the technology. Your technology choice should flow from the use case.

hdost
  • 883
  • 13
  • 22
  • so more or less, its same rest vs soap call! – Raúl May 19 '15 at 14:15
  • I would not say that they are the same, just that you need to look at the potential use cases you will be dealing with to understand which should be used. Additionally I would say that there is much to learn on both sides for SOAP, it's good to know about WSDLs, for both of them you want to know HTTP and it's error codes. For both of them you will want to explore HTTPS. The nice thing about using a RESTful service is that it's more reliant on HTTP error codes than SOAP is, since theres a separate mechanism for defining errors/faults within it. – hdost May 19 '15 at 14:34
  • Also as you can see there are a number of posts already on this http://stackoverflow.com/questions/209905/representational-state-transfer-rest-and-simple-object-access-protocol-soap/ http://stackoverflow.com/questions/76595/soap-or-rest-for-web-services – hdost May 19 '15 at 14:37
0

SOAP is a xml based protocol and REST is an architectural style for ROA (Resource Oriented Architecture), not a spec or a standard.

Web services vs. SOA and pretty URL vs. REST

  1. Having web services does not mean you have an SOA architecture
    This is perhaps one of the biggest misconceptions about SOA architecture I hear very very often. I see many developers thinking that if they have a web service or two in their architecture, they say their architecture is an SOA architecture. I think this comes because of two reasons: 1) “Web service” and “service oriented” resemblance in naming makes people think they are the same thing; 2) As web services are the most common way of implementing an SOA architecture, this pushes people think that when they have created one web service, their architecture is an SOA architecture.
    An SOA architecture is characterized of composition of independent services which encapsulate business functionality and expose it as a service, which can be a web service, a windows service, or any other form of exposure. Ubiquity of web and advancement of web development technologies which made the creation of web services easier have put web services as a mean of choice for implementation of an SOA architecture, however, the definition of a service within an SOA architecture does not put web services in any special position regarding implementation of SOA architectures.

  2. Having pretty URLs does not mean you have a REST architectural style
    REST architectural style is another popular topic lately, and as such, is subject to a lot of misconceptions as well. REST has brought simplicity to implementation of web services and is embraced very popularly from the web development community. It plays well with the HTTP protocol, which we are familiar with ever since the beginning of www era.
    One characteristic of REST architectural style is that resources are at the center of the architecture, and they are beautifully represented in URLs. REST has brought us pretty URLs, and therefore people have created a connection between the URLs and REST architecture. Leonard Richardson has developed a maturity model which tells the level of your API or RESTful services to what degree are RESTful.

source

Premraj
  • 72,055
  • 26
  • 237
  • 180