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.
Related
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
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 am little bit confused about what really a web service is. You say Amazone web services,etc like that, they offer information. So what is the requirement to be a web url to be a web service ? Let's say I am not much familiar with web development, how could you explain it to me ? But I can get it if you point some ways.
And also little about SOAP and REST basically for someone really new
What is a web service
It is many things. In programming, in generally refers to a web page, that can be called from an application (be it another web page, or desktop app), and the caller will pass in data to it, or receive data from it.
In this sense, it's basically like a 'method' or 'function' in a normal programming language; except you're calling it over the internet.
SOAP
A message format. As discussed above, a web service is a basically a 'method' or 'function'. SOAP is the 'instructions' and 'data' to this method. It will outline data types, and possibly a bunch of data as well. It is an XML format.
REST
REST is the means of implementing an interface to your application but, implementing access control, and other such things, specifically with HTTP Response codes. So you will get a 401: Denied (I think that's the right code), if you don't have access. There are other types of response codes that are useful. It also makes use of other HTTP commands like PUT/HEAD/OPTIONS.
The W3C defines a Web Service as (quoting) :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network. It has an interface described
in a machine-processable format
(specifically WSDL). Other systems
interact with the Web service in a
manner prescribed by its description
using SOAP-messages, typically
conveyed using HTTP with an XML
serialization in conjunction with
other Web-related standards.
That definition is maybe a bit too restrictive, considering how that term is used nowadays -- I'd probably go with just the first part of that definition, which is quite generalist :
A Web service is a software system
designed to support interoperable
machine-to-machine interaction over a
network.
Wikipedia also has some interesting definitions, like :
In common usage the term refers to
clients and servers that communicate
over the Hypertext Transfer Protocol
(HTTP) protocol used on the Web.
From what I've seen :
A couple of years ago, when we said "web service", we generally meant "SOAP, WSDL, ..."
Now, when we say "web service", we often mean "whatever allows to call something on another server, be it SOAP, REST, ..."
A Web-Service can be considered as a set of methods that enables communication amongst applications irrespective of the application's coding language or framework.
http://acharyashri.com/blog/WebServices.html
Think of Web services as remote APIs (since they are basically just that). You have a method that you want to implement. Let's suppose the method wasn't built by you and resides somewhere else in the world on equipment that you have no control over—how can you go about providing that remote method what it needs in order to get instantiated?
When you find a Web service that you want to include in your application, you must first figure out how to supply the Web service with the parameters it needs in order for it to work. That need also extends a bit further. Even if you know the parameters and types that are required for instantiation, you also need to understand the types that are passed to your application in return. Without these pieces of information, using Web services would prove rather difficult.
Just as there are standard ways to represent data as well as standard ways to move this data over the Internet using Web services, there is a standard way to get a description of the Web service you are interested in consuming. Web Services Description Language (WSDL) is a specification of XML that describes the Web services you are interested in consuming. It's just an interface to describe a web service.
Ok so I've implemented both REST and SOAP services and I like both depending on the context. For me, WS* is great when I want an explicit contract between the server and the client e.g. for sensitive information or for mission critical stuff. REST on the other hand whilst flexible in terms of the schema definition, is in my mind more ideal for content services or data which is not required to undergo any serious business logic.
REST seems to be very much the flavour of the day, and I was somewhat put out when Martin Fowler et al from Thoughworks gave this podcast: http://www.thoughtworks.com/what-we-say/podcasts.html on REST and were derisive toward WS*. Whilst the man himself is well respected, am I right in thinking that there still is very much a place for SOAP and pinch of salt is required here? And has anyone used REST in a serious business application?
Can you document your REST api by providing someone a description of the media types you use and a single URL?
If you find yourself providing a list of URLs and what verbs can be used on those URLs then you probably don't have a REST api.
Once you have created a true REST api then go back and compare it to WS* api. You will see they are very different.
REST apis can easily handle "serious business logic" and yes I have used REST in a serious business application.
Diary of a Fence Sitting SOA Geek - Dr Mark Little
Presentation is very recent - pretty revealing stuff.
REST actually works. It's not as good for repeat business as SOAP is. So many consultants fight to save SOAP on that basis. As the tools and frameworks for RESTful architectures improve, businesses will move in that direction. Governance is big talk at the moment also.
The new version of JAX-RS is a pretty interesting new tool for RESTful dev, Mark Little mentions this in his presentation.
You're probably better off considering SOAP as legacy technology, it'll serve you better going forward. ;)
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.