There is no doubt that REST is very useful specially in the B2C.
There are two approaches have emerged lately.
True REST and REST as a technology approach for services (REST web
services).
A true REST is effectively an implementation of Resource-Oriented
architecture and not a pure technology decision. So the right question
to ask when discussing true REST is whether its underpinning ROA - is
a good fit for your SOA implementation.
In order to assess the problem correctly, lets first recall that the
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.
Enterprise business services represent existing IT capabilities (aligned
with the business functions of the enterprise).
Business processes, which orchestrate business services, define the
overall functioning of the business.
REST, on another hand, is a set of architectural guidelines expressed as
Resource-Oriented Architecture (ROA).
ROA is based upon the concept of resources; each resource is a
directly-accessible distributed component that is handled through a
standard, common interface.
So, the foundation of ROA is a *resource-based
decomposition*<http://www.infoq.com/articles/RESTSOAFuture/#_ftn3_1498>.
In order to assess the applicability of true REST for the implementation
of SOA, the real question that we need to answer is What is the
relationship between a service and a resource?
Services vs. Resources
What is a service?
In the simplest case, a service can be defined as a self-contained,
independently developed, deployed, managed, and maintained software
implementation supporting specific business-relevant functionality for
an enterprise as a whole and is "integratable" by design.
A Service is defined by a verb ( For example, */validate/* customers
credit score, which describes the business function it implements.)
A service is not a programming construct or a set of APIs, but rather an
architectural (unit of design, implementation, and maintenance) and
deployment artifact used for implementation of enterprise solutions.
The service functionality is defined by a service interface (specific
for a given service), which can be supported by multiple implementations.
There are two basic ways of defining a service interface RPC-style and
messaging-style.
*RPC-style implementations* use service invocation *semantics and are
defined through a set of parameters in the service interface*.
In the case of messaging style, a service interface is effectively fixed
it essentially performs execute - with an XML document as input and
output (much like the GoF command pattern).
A service semantic, in this case, is defined by the semantics of the
input and output
messages<http://www.infoq.com/articles/RESTSOAFuture/#_ftn4_1498>.
Historically, services are often defined as a collection of methods,
these methods are independent from each
other<http://www.infoq.com/articles/RESTSOAFuture/#_ftn5_1498>and such
collection serves as a namespace, simplifying the management of the
services.
What is a resource?
In the simplest case, a resource can be defined as a
directly-accessible, independently-developed, deployed, managed and
maintained software artifact supporting specific data.
A resource is defined by a noun for example, doctors *appointment*
that describes the data provided by the resource.
A resource can also relate to other resources and provide a reference
(link) to them.
In effect, a resource is similar to an
object<http://www.infoq.com/articles/RESTSOAFuture/#_ftn6_1498>, but
with a predefined (CRUDish) interface semantic.
The semantics in REST are based on the set of HTTP operations and looks
as follows :
* createResource - Create a new resource (and the corresponding unique
identifier) - PUT
* getResourceRepresentation - Retrieve the representation of the
resource - GET
* deleteResource - Delete the resource (optionally including linked
resources) - DELETE (referred resource only), POST (can be used if
the delete is including linked resources)
* modifyResource - Modify the resource POST
* getMetaInformation - Obtain meta information about the resource - HEAD
A resource is defined by its URL and definition of inputs/outputs for
every operation supported by a
resource<http://www.infoq.com/articles/RESTSOAFuture/#_ftn7_1498>.
Unlike a service, where methods are completely independent and can be
deployed as independent endpoints, methods on a resource follow OO
semantics, which means that all of them (except /createResource/) have
to exist on the underlying resource (same URL).
Basic differences between Resources and Services
Based on the above definitions of resources and services, it seems
intuitively obvious that they are very different.
Lets delve into these differences first, and then discuss how they can
impact resulting architecture.
As stated in [Dhananjay Nene. Service oriented REST architecture is an
oxymoron.
<http://blog.dhananjaynene.com/2009/10/service-oriented-rest-architecture-is-an-oxymoron/>]:
/*Not only is REST not service oriented, service orientation is
irrelevant for REST*/
And [Dhananjay Nene. REST is the DBMS of the Internet ]
<http://blog.dhananjaynene.com/2009/06/rest-is-the-dbms-of-the-internet/> goes
even further explaining the differences between the two as:
/*If WS-* is the RPC of the Internet, REST is the DBMS of the
internet*/
Traditional SOA based integration visualizes different
software artifacts being able to interact with each other through
procedures or methods.
REST effectively allows each software artifact to behave as a set of
tables, and these artifacts talk to each other using SELECT, INSERT,
UPDATE and DELETE. ( or if you wish GET, PUT, POST, DELETE). And where
exactly is the business logic? Is it in the stored procedures? Not
Quite. Its in the triggers.
Here we will use a slightly different analogy, one based on J2EE.
We can think of services as stateless session beans and resources as
entity beans.
Services session beans serve as controllers allowing execution of a
required operation, regardless of the underlying resource.
For example, a debit account service might take the account ID and the
amount and debit required account. A single service can debit any of the
existing accounts.
Resources aka entity beans serve as a data access mechanism for a
given instance of given data type.
For example, in order to debit a certain account, it is necessary to
find a resource representing this account and then update it to debit
the required amount.
An additional caveat here is that unlike an entity bean which can
implement any required method, a REST resource has only a single /modify
resource/ method.
This means that the actual business operation, the debit, has to be
encoded as part of the request.
What does this mean?
Based on the above, it is impossible to build an SOA system using true
REST.
It is possible to build a system, but it wont be SOA.
Both will start with the business-aligned decomposition, but because
they are using very different decomposition approaches they will result
in completely different architectural styles[Dhananjay Nene. Musings on
REST]<http://www.infoq.com/articles/RESTSOAFuture/#_ftn8_1498>based on
different set of components and connectors.
Just because they are trying to solve the same problem business/IT
alignment and are both based on business driven decomposition *_does not
mean that the result will adhere to the same architectural style._*
Another question is whether it is possible to build a complete system
using true REST.
Based on the above, it is a question of whether it is possible to build
a complete system using only a database or entity beans.
Certainly you could, but it would require adding procedural code in the
form of stored procedures (overwriting the meaning of the methods) or
triggers (doing post processing based on the data changes).
The same is typically true for a true REST implementation you have to
change the meaning of the modifyResource method (often using command
pattern) to do more than data update.
As a result, *a REST-based implementation is rarely true REST*; it
typically includes at least some elements of REST Web Services.
So what does it mean to be a REST Web Service?
If you want to continue discuss and complete this subject in a
scientific manner, most welcome.
Please understand that we are not evaluating each other, we have
different opinions and want to reach to the best in a respectful manner.
All the best
Ashraf Galal
Post by Alexander JohannesenPost by Ashraf GalalThe main difference between SOAP and REST is the fact that
while REST is implemented directly on top of the HTTP protocol,
SOAP introduces an abstraction layer (SOAP messaging), that
can be implemented on top of any transport.
Hmm, that's actually misleading. REST is just as abstract and
technology agnostic as SOAP. It was developed at the same time as HTTP
- and, indeed, HTTP is the largest and most famous implementation of
REST - but does not rely on it.
Also, the SOAP envelope is almost identical to the HTML envelope (few
people seem to realize the header/body dichotomy similarities), and
I'd be hard pressed to find SOAP gliding over non-HTTP based
infra-structure.
No, if I'd point out differences, I'd choose ;
1) resource-orientation, where big and small systems are spread out
2) REST is simpler and more generic than SOAP
3) REST is supported by more tools, unknowingly
4) REST is harder to understand because of its higher-order flexibility
Post by Ashraf GalalI think the vendors do the right thing by supporting both REST and
SOAP, because REST is best fit into B2C interactions but not with
B2B interactions.
I think such broad categorizing is wrong. Since big business made WS
and tons of tools specifically to cater to B2B, most B2B are done
through big business and their tools. And this was done in the absence
of knowledge that REST could also do their job, not because it was
deemed unusable because, well, some businesses are indeed using it
B2B. However, people have a tendency to mean *their* B2B where they
already use WS and they can't phantom using anything else or their
industry or sector have invested billions into those tools and skills
and people.
Post by Ashraf GalalAdditionally, even if HTTP is the only transport used in implementation,
the SOAP envelope can become very handy for a clean separation of
business (SOAP Body) and infrastructure or out-of-bound (SOAP
Headers) data in SOAP messages.
You'll find this in HTML as well. In fact, a REST message have this,
as well, so I'm not sure you can claim this a WS victory.
Post by Ashraf GalalAccording to them, REST simplicity stems from the fact that REST does
not require WSDL or any interface definition.
I think you need to talk to "them" more often. :) And the answer has
far more context than simply WDSL and interface definitions.
Post by Ashraf GalalDefining an interface in a text document and manually coding of data
marshalling/unmarshalling based on a common interface definition
described in the interface document.
Give us an example.
Post by Ashraf GalalAlthough such an approach is often promoted by REST advocates,
it rarely scales beyond 10 - 15 elements, which is not typical for coarse
grained REST services.
Currently this is a straw argument, so how doesn't it scale? What doesn't scale?
Post by Ashraf GalalBesides, such an approach is very error prone and as a result, most
of the available REST frameworks have abandoned it in favor of the
next approach.
Again, what errors? Who's abandoned it?
Post by Ashraf GalalDefining an interface on the XSD level and generation of the data
marshalling/unmarshalling based on the preferred framework (for
example, JAXB or Castor in the case of XML payload or Jackson,
in the case of JSON payload). Such an approach is, in effect,
a minimalistic version of WSDL and requires about the same amount
of effort as SOAP-based implementations.
What? This is all data-binding and schema variations, and has nothing
to do with interfaces as such or as a special thing. Indeed, explain
why GET / content-type/xml+xsd somehow is harder or easier than any
other means. It isn't, of course, as neither REST nor SOAP cares about
data-binding nor data schemas, so not even sure why this enters our
discussion here, unless you're talking about defining APIs inside data
objects, in which case we've left REST /SOAP several abstractions ago
... :)
Post by Ashraf GalalAnother common complaint about SOAP is perceived complexity of WS*
standards. Although there is no single spec that lays out the key WS*
standards and their interrelationships, there is a standard for a majority of
service interaction use cases.
Hmm. A lot of these are API specifications, of which REST defines
*none*, so you can't make a comparison here.
Post by Ashraf GalalGranted, the choosing of an appropriate WS*standard and its usage might
require some extra understanding/implementation time, [...]
Understatement of the day. :)
Post by Ashraf GalalArguing simplicity versus standards is ridiculous in the war between
REST and SOA because simplicity without standards is just as
detrimental to the costs and manageability of an application
This doesn't even make sense. REST is in no way the opposite of SOA.
Is it supposed to say SOAP? Or is it supposed to say WS-*? And if so,
the argument becomes valid.
Post by Ashraf GalalSo, with the exception of the most simplistic examples like
temperature converters, REST is not any more simple than SOAP.
Wow. I didn't know all my enterprise BI, integration and development
were that simple! I shall promptly tell the people in charge to lower
my salary ...
Ok, maybe I'm not that good with sarchasm[1], but these statements are
in dire need of correction; they are simply wrong and mocking in tone,
and to me demonstrate a level of knowledge about the subject matter
far below par.
Regards,
Alex
[1] Sarchasm; the chasm between the person of brilliant wit and the
others who don't get it.
--
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---
------------------------------------
Yahoo! Groups Links