1

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?

Community
  • 1
  • 1
VB_
  • 45,112
  • 42
  • 145
  • 293
  • Seems not a good question for SO but another stackexchange site – Gilles Quénot Sep 19 '16 at 20:19
  • @GillesQuenot suggest me pls another site where I can get an answer for this question. – VB_ Sep 19 '16 at 20:24
  • @GillesQuenot this question is a poor fit for Programmers - it would be quickly voted down and closed over there, see [Discuss this ${blog}](http://meta.programmers.stackexchange.com/a/6418/31260). Recommended reading: **[What goes on Programmers.SE? A guide for Stack Overflow](http://meta.programmers.stackexchange.com/q/7182/31260)** – gnat Sep 19 '16 at 20:32
  • @GillesQuenot I noticed you have earned zero reputation on Programmers and have never posted (or your posts are deleted). Please refrain from suggesting [cross-posting](http://meta.stackexchange.com/tags/cross-posting/info) especially when it concerns communities that you do not participate in. –  Sep 19 '16 at 20:33
  • 1
    Hey guys, I just know that SO is for coding questions (you know, problems with real life code), and I guess this one is not one of these. – Gilles Quénot Sep 19 '16 at 20:36
  • TL;DR all the linked thread, but I'm on SO for years, where to post conceptual questions is quite vague – Gilles Quénot Sep 19 '16 at 20:45

2 Answers2

2

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!

tonicsoft
  • 1,736
  • 9
  • 22
  • thak you for answering this question! Sorry, but I still need somrone bring a light to the non-REST parts. I updated my question, could you pls take a look? – VB_ Sep 19 '16 at 21:22
  • 1
    Answer updated - I don't think it matters too much as long as your app is well organised into different URLs. It's completely fine to have pure REST and non-pure REST endpoints in the same app. – tonicsoft Sep 20 '16 at 09:00
0

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

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.

Community
  • 1
  • 1
inf3rno
  • 24,976
  • 11
  • 115
  • 197