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!
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.
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
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.
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
Related
Is REST the future for SOA:
SOA architectural style is based on a functional decomposition of
enterprise business architecture and introduces two high-level
abstractions: enterprise business services and business processes...
REST, on another hand, is a set of architectural guidelines expressed
as Resource-Oriented Architecture (ROA). ROA is based upon the concept of resources;
... it is impossible to build an SOA system using true REST.
and
The REST Web Service approach is an approach for using REST purely as
a communication technology to build SOA. In this case, services are
defined using SOA style decomposition and REST-based Web Services
are leveraged as a transport.
Could you pls explain in more details the last quote? Did they mean RESTful Web Services is smth different from REST or not only a REST or what? What did they mean by use REST as a communication technology? What did they mean by "REST-based Web Services are leveraged as a transport"?
Update: for tonicsoft answer
Due you can't build SOA with pure REST (like sentence with pure nouns) I'm wondering what is the right way of arranging app parts where REST is appropriate and where isn't? Should I separate REST-part from not-REST parts? How not-REST part should comunicate among each other and with REST parts?
Yes, the article is stating that REST is something different to "RESTful web services".
The author compares REST to "nouns" as opposed to verbs, or the "DBMS" of the web. Can I write a sentence without using verbs? No. Can I build a system using only a DBMS? No. In the same way, one cannot build a system only using REST architecture principles. In most systems REST semantics break down eventually. One example given in the article is when a messaging solution is required.
I think the author is saying the a "RESTful web service" is the whole sentence whereas REST is just the nouns. In a "RESTful web service", the parts of the system which do not have REST semantics (basically anything that is not CRUD) can be implemented using similar technologies and programming styles often found in the implementation of pure REST components.
"REST as a communications technology" basically just means restricting the transport implementation of the service to HTTP. Most web services frameworks provide multiple options for the transport (e.g. WCF can do SOAP over HTTP, or use shared memory, or TCP for networked services without HTTP). REST shuns this flexibility in favour of simplicity. A "RESTful web service" will be purely HTTP based, according to my interpretation of the quoted article.
In summary, REST is simply an architectural style. It is impossible to build any technology solution of note using only one architectural style. Therefore a "RESTful web service" is simple a web service that leverages the REST architectural principles where appropriate.
Again, this is not my opinion, it is simply my interpretation of what the article is saying.
How to seperate pure REST operations from the rest of your "RESTful web service"
I don't think any particular seperation is needed between the pure "REST" endpoints (CRUD) and the more behavioural/service oriented endpoints, beyond the fact that any given URL should be either one or the other, and you may find that you don't want to mix the two styles under the same base URL. For example, if you have a REST endpoint for retrieving the details of a user account with id=1234:
/users/id/1234
and you want to implement a "verify email" workflow (which for argument's sake is not implemented as a REST service), then choose a URL for your verify email workflow/service that doesn't clash with the REST style /users/ API. Don't be tempted to do things like this:
/users/id/1234/verifyEmail?securityToken=XXXX
but instead, prefer to create a completely new URL for this endpoint:
/verifyEmail/userId/1234?securityToken=XXX
These guidelines are largely arbitrary: the important thing is to design your service in a way that will make sense other programmers, as these are the people who will use your service. As with any other bit of software design, Single Responsibility Principal will get you a long way. Each base URL should only do one thing!
As mentioned in th e introduction, the H ypermedia as the E
ngine of A pplication S tate (HATEOAS) constraint is one of
the least understood constraints, and thus seldom implemented
correctly. Annoyed by the fact that a lot of services claim
to be RESTful regardless of violating the hypermedia
constraint, Fielding [29] made it very clear that hypermedia is
a fundamental requirement but since the term REST is so widely
misused, there are e fforts in the community to look for an
alternative term, such as Hypermedia API , to denote truly
RESTful services
http://www.ws-rest.org/2012/proc/a4-2-lanthaler.pdf
http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
The REST architecture has well defined constraints you can find here: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
The term RESTful comes from the Richardson Maturity Model as far as I know. http://martinfowler.com/articles/richardsonMaturityModel.html I don't know where the original article is, but as far as I know it is some nonsense, something like you should call every API REST, which fulfills at least a single constraint and you should call RESTful only those APIs which fulfill every REST constraint. Fielding made clear many times that only APIs which fulfill all constraints are considered REST and APIs which don't are simple web APIs, but not REST APIs. Sadly both REST and RESTful words are overused by developers who know nothing about REST. Most of them don't even know that REST constraints exists. For them REST is only CRUD and URI design. Just check SO questions about REST, 99% is that kind of stuff. Even funnier that I get minus points from them when I answer questions related to REST... So to avoid confusion and misunderstandings we build Hypermedia APIs now, so we can live in piece as long as people do not start to use this word as well...
I cannot make sense from most of the questions. I compared REST and SOAP here along with many people Representational state transfer (REST) and Simple Object Access Protocol (SOAP) maybe you find an answer to your questions.
How not-REST part should comunicate among each other and with REST
parts?
If you mean microservices by app parts, then ofc. SOA and REST microservices can communicate with each-other simply by sending HTTP and SOAP messages to each-other. If you don't have a legacy SOAP system, then I recommend to develop only REST services, since SOAP is stateful, and so it does not scale as well as REST.
The title basically says it all, is REST really tied to HTTP or is it protocol independent?
Because I've just read few articles about REST and I encountered both opinions so I don't know which one is correct.
Allow me to quote the book "RESTful Web Services" (bold is mine):
The Story of the REST
REST is simple, but it’s well defined and not an
excuse for implementing web services as half-assed web sites because
“they’re the same.” Unfortunately, until now the main REST reference
was chapter five of Roy Fielding’s 2000 Ph.D. dissertation, which is a
good read for a Ph.D. dissertation, but leaves most of the real-world
questions unanswered. That’s because it presents REST not as an
architecture but as a way of judging architectures. The term “RESTful”
is like the term “object-oriented.” A language, a framework, or an
application may be designed in an object-oriented way, but that
doesn’t make its architecture the object-oriented architecture. Even
in object-oriented languages like C++ and Ruby, it’s possible to write
programs that are not truly object-oriented. HTTP in the abstract does
very well on the criteria of REST. (It ought to, since Fielding
co-wrote the HTTP standard and wrote his dissertation to describe the
architecture of the Web.) But real web sites, web applications, and
web services often betray the principles of REST. (...)
Notice in the second bold, he's saying: "HTTP fits REST well", not "REST fits/depends on HTTP".
So, in short: no, the term "REST" is not necessarily tied to HTTP. RESTful web services are just web services that follow a RESTful architecture, hoping to achieve the benefits listed by Fielding in his thesis (such as statelessnes, addressability, etc.).
One way to create RESTful web services is to think of you application in terms of resources (not actions, as the SOAP style uses). Such way of thinking in conjunction with proper usage of HTTP (its methods and status codes) can lead to a REST-enabled architecture as (and with all the benefits) Fielding's thesis enumerates.
I was wondering if someone has successfully implemented a RESTful Shopping Cart Web service. I am perticularly interested in Production level implementation rather than test app.
Would there be any advantage in this approch rather than SOAP-style?
Personally, I haven't. I would be completely astonished if somewhere in the world "someone" has not. I know of plenty of equivalently important RESTful services running in production or production ready. As an example one of my employer, IBM's, flagship products WebSphere Process Server, exposes restful services.
I'm guessing that you are asking the question from the perspective that suspects that RESTful services are not yet mature. My experience is that because of their relative simplicity the support stack for such services reached maturity quite quickly. In the Java world JAX/RS is very easy to use and seems to me to be very stable.
Advantages: Simplicity, really easy to consume from JavaScript, especially with JSON payloads, potential for much simpler life-cycles and versioning than with WSDL.
Disadvantages: the more advanced WS-* capabilties are not available as standard.
I'm designing a set of web services to allow our clients to connect from their apps to one of our systems. Our clients have their apps developed in all varieties of frameworks (.NET, Java, PHP, Python and even the occasional all JS app), so obviously WS is the way to go.
Investigating a little about truly interop WS I've found that the way to go is to design first the WSDL and XSD and derive the implementations from there.
What i'm really looking for is guidance if this is really the way to go. I've read that WCF creates interoperable WS but i'm not a fan of MS creating something standard.
Should i use WCF or there is a good set of tools for designing WSDL and XSD without the pain i'm expecting.
Thanks in advance
If you want to interoperate with JavaScript, then best to make more of a REST style API. This is basically just standard HTTP calls, so you're interopable from the get-go. However, you've kindof indicated that you want to use SOAP, so ...
If you're going with SOAP/WSDL, I'd definitely advocate using the server platform - yes, even .NET - to generate the WSDL, then simply check that the options you're using are producing a good, interopable WSDL.
I'm a Java developer with a history of PHP & Perl, and I've interoperated with .Net on a number of WS projects, from both sides of the coin (as server and client). There's usually no major problems - just be wary of a couple of things:
certain proprietary elements that MS
mixes in with the open standards. For
example, they may offer NTLM-style
authentication, which really isn't
needed in most use cases,
particularly when you're using SSL
certificates.
SOAP has taken a few
different forms over the years
(Document/Literal, RPC/Encoded, ...)
you'll probably find you don't need
to worry about this, as RPC/Encoded
died along with old frameworks, and
most modern frameworks tend towards
Document/Literal
SOAP offers a few
bolt-on standards (e.g. MTOM & DIME
for attachments, and SOAP-WS for
authentication). Try to avoid those
bolt-ons, as different platforms
implement different subsets.
For security, I'd advise to use SSL for
the trust & confidentiality, and then
either HTTP basic auth, or simply custom
string tokens in your soap request definition.
Just keep the WSDL as minimal as possible, try interoperating quite early in the process, and you shouldn't have too many problems
You can use WCF and contract-first development.
If interoperability is the main concern then I would recommend using WCF to provide the service implementation but instead of relying on WCF to generate the service interface to use contract-first development to model the interface.
A really good article on how to develop this way is Schema-based Development with Windows Communication Foundation.
If you are going to roll your own WSDL and schemas you are probably going to want to get an editor like XmlSpy or LiquidXml. I like the price of LiquidXML (free!) but I can't recall if you have to pay for the web service features.
Another interesting tool for contract-first development with Visual Studio and WCF is WSCF.blue. I haven't used it but it does appear to be actively developed based on the WCSF.blue roadmap.
WSDL and XSD are language independent, you just have to have some mechanism to communicate using other languages. Good thing for you to do would be IMHO core data design, so you would not need so many XSD for the same data entities.
I'm not sure what you mean when you ask "should I use WCF"? WCF is the current mechanism for developing web services (and other kinds of communicating services) on .NET. There is no other current mechanism. The others are obsolete, or else considered "legacy technology".
I'm beginning a project right now that will require a pretty extensive web back end. Of the different calling conventions, we have found that the easier and more cost effective approach is to build a standard SOAP web service.
So now, we are in the process of looking at the different web service frameworks in order to determine which will meet the business needs:
Security
Cost
Time
I've only worked with WCF, which I was fairly content with, but I would like to explore all other options before I make a definite decision. In your experience, what do you feel is the best web service framework?
Web Services Interoperability Technology (Java)?
WCF (.NET)?
ActionWebService (Ruby)?
On a side note, we need a framework that can securely be accessed via iPhones, Windows Mobile Devices, and Blackberries.
Thanks in advance for your help.
Chris
WCF can be used to make both SOAP and RESTful Web Services. Interoperability is guaranteed as long as you stick to standards. But the more standards you put on it, less platform can catch up. In that sense REST on Basic Auth over https would be very light weight. Also see WS-I Basic Profile. Java vs .NET would be matter of taste, I think. WCF is not perfect, but it mostly seems to do the job.
One thing to consider about WCF is that it has a very rich extensibility model. Anything it doesn't do out of the box, you can teach it to do, with little or no change to your basic service.