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. ;)
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.
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
may I have some example/typical use case of HATEOAS? I agree it can be a very powerful concept provide great flexibility but I am not sure how to properly get benefit from HATEOAS. would be great if you can share your experience/use case.
A good answer from #dreamer above, but HATEOAS is not present in most REST-based services. It is a constraint on the REST architecture style that allows clients to interact with a service entirely via the hypermedia contained in the resources.
If you look at the Twitter or Facebook REST APIs, you won't find hypermedia. Look at the Facebook friendlist resource. There are no hypertext links in that resource that you can use to transition the state of the resource - to delete, update, etc. Instead, you need to read the out-of-band documentation to understand what you need to do to delete that resource.
One of the claimed advantages of using hypermedia in your APIs is that you can manage change within the resources themselves. For example, what if Facebook wanted to add additional functionality to the frendlist? If it were built with HATEOAS in mind, the resource would be updated to add the hyperlinks provides those additional state transitions.
If this sounds difficult, you're right. But as a developer of client applications, however, once you understand how the hypermedia is presented, you can build applications that will evolve along with the API itself.
So how do you build APIs using HATEOAS? A number of options are out there, but I like the Hypertext Application Language (HAL) the best.
UPDATE: Since you asked for an example, here's a link to a demo using HAL.
Good public HATEOAS use cases are hard to find, because there are a lot of misconceptions around REST, and HATEOAS can be hard to implement. You really need to have a good understanding of its benefits, before you're willing to put yourself through the trouble of getting it to work, and if the clients don't follow it correctly, all work will be in vain.
From my experience, implementing proper REST in a company is a culture change as important as moving to version control systems or agile development. Unless everyone adopts it and understands it, it causes more trouble than it solves.
Having that in mind, I think the best example one will find is the foxycart.com HAL API, on the link below:
https://api-sandbox.foxycart.com/hal-browser/hal_browser.html#/
It's very powerful concept used in RESTful presentation of the application to the client. There are many many projects which are adopting this interface now. A typical use case for this is Web Services APIs using RESTful APIs. A RESTful APIs typically consists of the following elements:
base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources
The application state can be modified using above HTTP methods for example, to get a particular resource, A client can issue a REST query using curl like:
curl -X GET --url "http://example.com/resource/" -X "Content-Type:application/json"
you could go through the man pages for curl and its usage. More on RESTful interface concepts can be looked upon at wiki
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 thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck