Volodymyr Bakhmatiuk Volodymyr Bakhmatiuk - 1 year ago 82
reST (reStructuredText) Question

REST vs RESTful Web Service

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.


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?

Answer Source

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:


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:


but instead, prefer to create a completely new URL for this endpoint:


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!