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.
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
We'll be developing mobile applications (for both iOS and Android platforms) that will be using web services. I'll be the one implementing the web services part and I plan on using Apache CXF.
It would be the first time I'm using CXF but I'm highly considering it because of its integration with Spring.
What are the potential issues (if any) with using CXF for mobile apps? If there are, is there supposed to be a better alternative to CXF? If there are none, any best practices I should also be considering?
Thanks!
I've been through the mobile ringer... WAP, J2ME, Brew, embedded languages, etc. Mobile development is exciting and also a bit scary...
Spring Integration: There is a big difference between * and **... be careful when setting up filters. It's easy to get out of hand securing end-points.
Authentication: How will your mobile devices authenticate and what is their role in Authentication, Authorization, and Access? Session management on occasionally connected devices - can get interesting. If a session goes stale how are you going to handle challenge / response?
App Security: Does your solution require SSL? Managing self-signed certificates is painful and time consuming. Do yourself and your mobile devs a favor and get a CA certificate in place up-front. You will save time (money) and a great deal of headache.
Proxy Power: Ideally, the people writing the front-end should be using an IDE that supports some kind of tethering for realtime debugging. Being able to add a breakpoint and introspect what's going on in the code... is mint. However, I haven't seen an IDE yet that gives front-end mobile devs the same experience as back-end devs. My guess is that your mobile devs are going all goo-goo eyes over jQuery. Understandably so! WebStorm and Aptana are good in the JS arena - but they're still evolving.
This is a problem front-end mobile devs need to work out... right? Yes... and no. Without proper tools everyone in the dev-chain will have to cook-up their own ways of answering questions like:
What did the mobile app send?
Was the request formed correctly?
What was the response?
Again, save yourself some time and finger-pointing and just sit down together (front and back-end devs) and work out a tech-stack that provides everyone optimal access to all app communications. Configurable logging on the server is a good idea to have in place from inception. Are you familiar with Firebug or Charles Proxy? A proxy can greatly simplify the debugging equation - just sayin'
Exceptions: Oh... and beware HTTP response codes. Exceptions on the server-side should be gracefully handled to prevent mobile consumers from choking on responses. Yikes - that's all I can say is YIKES!
Service / Life Cycle: Have you calculated the duration of the service and / or life cycle of your application? Knowing this can greatly impact architectural decisions.
Web Services: My knee-jerk reaction - is this the best technology for your product? Why Web Services? Can you come up with three concrete reasons why WS is the best option? From my experience, the most compact protocol will usually lead to the best user experience.
Food for thought... ASP.NET and JSon make a good pair.
http://encosia.com/using-jquery-to-consume-aspnet-json-web-services/
SOAP-XML is cumbersome. :-(
http://openlandscape.net/2009/09/25/call-soap-xm-web-services-with-jquery-ajax/
Have you considered RESTful Web Services? If you're using CXF... there are three different ways to build RESTful Web Services.
JAX-RS (CXF has an implementation of JSR-311 baked-in)
JAX-WS (more complicated - meh)
HTTP Binding (deprecated... may be removed from CXF in the future - fair warning)
More at: http://cxf.apache.org/docs/restful-services.html
Examples: http://solutionsfit.com/blog/2010/04/21/enterprise-mashups-with-restful-web-services-and-jquery-part-1/
Alternatives: There are so many great projects out there... Axis2 and Shiro come to mind. Without knowing more about your solution - it's difficult to recommend anything.
Final Thoughts: As a back-end dev, I would recommend getting familiar with the entire app tech stack and kick-off development with a series of small but functional samples that light the way through the obstacles mentioned above. Hold-on to the samples! They may prove useful in zeroing in on regression.
Mobile devices are getting faster and faster every day... it's true, but any dev worth their salt will know that they need to code to a common denominator if they want a mobile product to be widely consumed, adopted, and embraced.
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. ;)
I'm beginning a project right now that will require a pretty extensive web back end. Of the different calling conventions, we have found that the easier and more cost effective approach is to build a standard SOAP web service.
So now, we are in the process of looking at the different web service frameworks in order to determine which will meet the business needs:
Security
Cost
Time
I've only worked with WCF, which I was fairly content with, but I would like to explore all other options before I make a definite decision. In your experience, what do you feel is the best web service framework?
Web Services Interoperability Technology (Java)?
WCF (.NET)?
ActionWebService (Ruby)?
On a side note, we need a framework that can securely be accessed via iPhones, Windows Mobile Devices, and Blackberries.
Thanks in advance for your help.
Chris
WCF can be used to make both SOAP and RESTful Web Services. Interoperability is guaranteed as long as you stick to standards. But the more standards you put on it, less platform can catch up. In that sense REST on Basic Auth over https would be very light weight. Also see WS-I Basic Profile. Java vs .NET would be matter of taste, I think. WCF is not perfect, but it mostly seems to do the job.
One thing to consider about WCF is that it has a very rich extensibility model. Anything it doesn't do out of the box, you can teach it to do, with little or no change to your basic service.