I’ve been trying to do some research on REST and SOAP web service supporting frameworks for CentOS/Redhat that would also be able to reasonably support a management Web application along side the services themselves.
We haven’t determined if REST or SOAP will be the way to go for service communication. The communication requirements are pretty straight forward, so a heavier SOAP interface may not be required. (but wouldn’t be complex either)
I’ve done work with Ruby on Rails in the past (on the side currently) but the technology isn’t as familiar to the rest of my group as J2EE would be.
ServiceStack is also interesting (I’m looking into it now) but I’ve worked on .Net/Mono projects in the past and have run into all kinds of Mono implementation and runtime issues. (I’m sure it’s come a long way in the last 2 years, but I’d like to see if there’s a better alternative)
Basically I need a stack/framework which supports REST or SOAP, (both would be amazing) and can support a MVC style Web app. The idea is the Web service and Web app would have access to the same database. The Web app would be an end-user/admin management interface, and the Web service would be for remote system/automated access to controlled data.
Finally, about 80% of the application database schema will be predefined and won’t follow any MVC style modelling. So a framework which is intended to tightly model the schema data for MVC only use, like Ruby on Rails, wouldn’t be preferable as we’d end up having to re-create the Models or write an entirely separate database query handling library which both the Web service and Web app would have to use. It would be great if existing data could be modelled more flexibly. (in case the existing schema changes at a later date)
Sorry if I’m being too generic. (or specific) I’m just interested in opinions. Thanks!
REST and SOAP are very different in many ways.
REST is an architectural style, SOAP is a protocol. SOAP defines how things communicate, REST defines how the’re described statelessly.
I do prefer REST with HATEOAS (Hypermedia As The Engine Of Application State). An application with that architecture exposes resources with specific URIs (like http://example.com/users) and representations (in JSON, XML, HTML, etc) for these resources using content-negotiation (Accept headers on HTTP).
The HATEOS part is the linking between resources, like
<a href=on HTML or<link href=on ATOM or JSON Schema for linking in JSON.A good reference implementation is the Netflix API http://api.netflix.com/. They’re awesome.
Frameworks for RESTful implementations are available for several languages. On Ruby, Sinatra is probably the best choice. Flask would be the guy for Python. On node.js, expressjs is getting very popular.
I’m a PHP guy. Of all frameworks I know (including Zend, Symfony, Slim, Code Igniter and many others), the best REST implementation is this http://documentup.com/Respect/Rest. It’s the single one that implements content-negotiation in a sane manner. (Disclaimer: I’ve coded it, my opinion may be biased. Get your own opinion using something like the Litmus Test for RESTful Frameworks http://code.google.com/p/implementing-rest/wiki/LitmusTestForFrameworks).
There is a single case in which I do prefer SOAP communications: when the client consuming my service already uses SOAP for anything else. Consistency wins on this case. Java guys would probably prefer SOAP as well, I believe.