Related
The other day I was explaining my friend that REST is an architecture style that relies on a stateless, client-server, cacheable communications protocol. One of the points was trying to make was the fact that REST has nothing to do with HTTP (even if, virtually in all cases, the HTTP protocol is used for designing networked applications). However, I couldn't come up with single real world example that implement REST using other protocol or RPC mechanism.
Does anyone know a real world system that implements REST on communication mechanism other than HTTP?
Here is one called Constrained Application Protocol (CoAP). Obscure, no doubt.
1060 Research's Netkernel implements an architectural model they call Resource Oriented Computing (ROC) which is a generalization of the principles underlying REST (state is represented in immutable entities exchanged between actors). It is targeted mostly at HTTP, but their ROC concept works independently of it.
AtomPub - the The Atom Publishing Protocol - is based on REST principles as well. See the specification.
I'm working on a personal project which is an RPC (client-server) in C++. The RPC will communicate over TCP/IP or HTTP. The spec of the RPC is here :
http://groups.google.com/group/json-rpc/web/json-rpc-2-0
I'm wondering if there is an existing design pattern (or a combination of pattern) that could help me to produce a clean and flexible design. I will appreciate to have code examples, UML diagrams, or articles.
Thanks.
You are probably going to need a Proxy on the client to represent and make callable locally any server-side methods that you will be calling.
Under the covers, Abstract Factory could be useful to encapsulate provision of a concrete network connection that is selected using a configured or requested protocol (TCP, HTTP).
I would go for Observer.
Details and diagrams.
It's not clear if you asking in regards to high level design (observer patterns, JSON/XML processing techniques, etc.), low level design (sockets, HTTP client/server handling, etc.), or both.
If interested in lower level aspects including scalability, it might be worthwhile to study the design and motivations behind ASIO: http://think-async.com/Asio/asio-1.3.1/doc/asio/overview.html .
Call me a troll if you want, but I'm serious: how exactly is the new SOA trend any different than the client-service architecture that I was building 15 years ago? I keep hearing SOA but I don't see how it's different than what we've always done.
Back 10 years ago, my company had multiple clients (in multiple languages) which talked to the same service. It wasn't XML (it was a binary protocol called Microsoft DCOM) and there wasn't auto-discovery through WSDL but that's OK since reading the docs was just as easy. Our system was even "open" in the sense we documented it enough to allow 3rd parties to talk to our services. We were not pioneers - every other company I knew 10 years ago was doing the same thing.
The ONLY difference I see between then and now is that now there's a single service available on the internet, whereas 10 years ago, each customer would host his own instance of the service. But that's not an architecture issue - where the service physically lives is transparent to anyone using the service.
So what exactly is SOA that's different than what we've been doing for years? Is SOA simply a marketing term representing a best practice that actually became common a long long time ago? Or am I missing some subtely to SOA that's different than what we've been doing all along?
Forget about XML. Forget about WSDL. SOA is not a technology you can buy, though it's often marketed that way.
The real point of SOA is all about IT organization. The point of SOA is to avoid having a huge bunch of "applications" that have isolated data pools and either don't talk to each other at all (and thus often duplicate data), or only in an inefficient, buggy way through adapter layers or EAI systems.
For large companies, this is a serious problem - they have literally hundreds of separate apps that are insufficiently integrated. There's duplicate and inconsistent data everywhere and the result is that customers get pissed off and real money is lost because the billing department keeps sending invoices for a cancelled order and the customer service rep can't even find the order because it's cancelled in the order tracking system, but not the billing system.
SOA is supposed to solve this by designing every app from the ground up to publish its services in a standardized, cross-platfrom manner so that other apps can access the data and don't have to duplicate it.
From a business perspective, this is highly desirable. The buzzword hype and the acronym soup is just IT companies' attempts to cash in on that desirability. Unfortunately, this has (mis)led many people, including CEOs into believing that SOA is a product you can buy and it will magically make your IT more efficient, without realizing that this will only happen if you also reorganize your entire IT (and quite possibly your business units as well) to be SOA-compatible.
Let me use the famous whipping boy of Integration Hell: Telco.
Way back in the 90's, cell phone companies were plethoric in my neighborhood, almost as plentiful as the long distance resellers made possible by the communications deregulation of the mid 90's. Well, time goes on, and Bell Atlantic becomes the powerhouse that is Verizon, and swallows up company after company (and at least one Baby Bell). Every single one of these companies has technologies in place, in towers, in switching equipment, in billing systems that are COMPLETELY incompatible with one another.
So the company goes off and says, okay, we have these models for how we do business, let's put a friendly, consistent face on ALL of our technology in the form of WSDL/SOAP/XSD - every language and system we have today can be interfaced to this! Slowly but surely, the company is making all of it's systems capable of reporting on capabilities, being interrogated for load and billing purposes, and exposed for future visionaries to exploit in manners that haven't been accounted for yet.
Anyone can build a SOA client. Anyone with wget and a text editor. And anyone can parse the results (XML).
That is what's fundamentally different from past client/server architectures. I was just talking the other day to someone about interfacing Cobol and Smalltalk based systems to SOA architectures. That's an easy problem to solve. Tell me you can say the same for your DCOM systems.
SOA is nothing but a way of design, in which the modules comunicates with each others through "services". It is just that, and now the next question is: what is exactly a "service" and what is its difference with a regular "method"??
A service is an operation that performs a single, atomic business operation. This atomicity make it highly reusable from many modules. Then a complex business operation is just the orchestation of the invokation of many of these services in a specific order.
SOA has nothing to do with specific technology, is just an specific way of designing.
Professor Frank Leymann from the University of Stuttgart takes SOA as a key concept for his Service oriented Computing (SOC) research work as he speaks about SOA. He is seen to be asked about the definition of SOA and the ensuing conversation could be a good read.
Please note that our roadmap is about "service oriented computing (SoC)", i.e. the compute paradigm behind service-orientation. Service Oriented Architecture (SOA) is an architectural realization of this compute paradigm. You may compare this with "client/server computing" as paradigm and "browser/web server" or "DB-client/stored procedure" as two (of various other) architectural realizations of this paradigm.
...
SOA is not completely new. Some individual aspects of SOA are used in practice for a long time. For example, take a look at "loose coupling": Enterprises are using reliable messaging technology since decades to integrate applications, i.e. to loosely couple them. Don't get me wrong, there are new concepts in SOA, e.g. concepts resulting from the combination of concepts put together in SOA, i.e. they result from emergence.
Web Service specifications make the corresponding technologies available cross platform. I.e. the corresponding specifications do not invent fundamentally new concepts but define how these concepts and corresponding implementations work in heterogeneous environments. The resulting interoperability is groundbreaking, making SOA real.
In summary, SOA is a mixture of mature things and new emerging things.
There is also a SoC paper reference dated April 2006.
A google search identifies Prof. Frank Leymann and his works.
Neal Ford has many strong opinions regarding SOA. You might find his viewpoint interesting.
Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)
Standards Based vs. Standardized (SOA & the Tarpit of Irrelevancy)
Tools & Anti-Behavior (SOA & the Tarpit of Irrelevancy)
Rubick's Cubicle (SOA & the Tarpit of Irrelevancy)
The Triumph of Hope over Reason (SOA & The Tarpit of Irrelevancy)
Guerrilla SOA (SOA & The Tarpit of Irrelevancy)
I think SOA is both a marketing term and an integration of existing solutions with the idea of instead of selling the whole software or machine, we sell the services.
For me, a Service Oriented Architecture comes about when an Enterprise wishes to integrate a selection of disparate applications which concern a common domain into a set of interoperable services which operate against a single data source.
In the case of a new startup company with an idea for an item of software/suite of softwares, I can't see how a company can kick off with a Service Oriented Architecture from the off. At first, each solution (which may well evolve into a service such that it may become interoperable) should seek to solve its problem space in isolation.
Perhaps it will be in the roadmap for an enterprise capability or suite for each solution to become an interoperable service as the solutions are completed and enter service. For this, perhaps the development teams will undertake a modular/component oriented approach to building the soluton (eventual service), so as to make it easier to include the solution as a service in a Service Oriented Architecture.
In the case where existing islands of software are to become interoperable services in a Service Oriented Architecture, the approach allows for the software items - which may be distributed and may be written in different languages - to communicate via an exposed API and/or common protocol (for example a flavor of Web Service) and generic data format (for example XML).
SOA is an approach or idea. It is not a framework or a tool. When WDSLs and EJBs get name-dropped, this is often forgotten... as is that the idea of SOA is not new at all.
Most of the answers here seems to convey that SOA (Service Oriented architecture) is about building application in a standardized manner so that other applications can interact with it in platform independent manner.
I am not sure if meaning has changed since but I have had an opportunity to work with a company that offers SOA suite and following are my thoughts on it.
Of course when you design an application you cannot guarantee it will be cross platform compliant. Take for example stock Trading systems. They use Fix protocol to transfer messages. Do you expect it now to return data in XML format so that it can be so called SOA compliant? Definitely not! SOA is an architectural approach that can help you decouple your application/services and let them interact with each other. Backbone of SOA is a ESB (Enterprise Service Bus) which is used to transfer data from one service to other. SOA architecture should take care of formats conversions. For example -
FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)
These conversion modules are commonly called as adapters and are generally part of SOA suite. For a bit more information refer to another answer -
Difference between SOA and ESB
Sure SOA is a word is hyped for marketing purpose. Technically speaking it as simple as de-serializing and serializing data so that services can be decoupled and platform independent but the idea behind it is concrete.
Also refer Wiki page for the same.
In reality, SOA is a collection of well-defined services. Basically SOA use loosely coupled service to get the desire result easily. Implementation details of a service are hidden from the client/consumer so any change in the implementation doesn’t affect the service until the contract between them is change. Service providers are components that execute some business logic based on predetermined inputs and outputs, and expose this functionality through an SOA implementation. This allows systems based on SOA to respond more quickly and cost effectively for the business. The main difference between component and SOA is that, SOA provide a open standards message which is not specific to any programming language or platform. As a result, you can achieve a high degree of loose coupling and interoperability across platforms and technologies. In a traditional client-server world, the provider will be a server and the consumer will be a client.You can read more about SOA here :Service Oriented architecture (SOA)
A service-oriented architecture (SOA) is an architectural pattern in which softwares are designed as building block. i.e. Modular development, which makes flexibility to assemble any way we want. If you want to start new project instead of starting from scratch, we can reuse the services and if you want to new service we can easily integrate with existing service to make new project. So we can save lot of time and money.The basic principles of service oriented architecture are independent of vendors, products and technologies.
Analogy: Toys build using Lego building blocks.
In fact, SOA also utilizes client-servier architecture. In addition, SOA is a way to design your software. Suppose that your application can break into simple and independent tasks like search a book, add new book, recommend a book according to user preference and so forth. If you consider a service (an API) for each of task, actually, you are using SOA. The advantage of this architecture is doesn't matter you're building a web app or mobile app, you only need the developed aforementioned services (APIs).
Service-oriented architecture (SOA) is a design approach where multiple services
collaborate to provide some end set of capabilities. A service here typically means a
completely separate operating system process. Communication between these services
occurs via calls across a network rather than method calls within a process boundary.
SOA emerged as an approach to combat the challenges of the large monolithic
applications. It is an approach that aims to promote the reusability of software; two or
more end-user applications, for example, could both use the same services. It aims to
make it easier to maintain or rewrite software, as theoretically we can replace one service
with another without anyone knowing, as long as the semantics of the service don’t
change too much.
Related:
Why would one use REST instead of Web services?
When deciding whether to implement a web service using SOAP or REST (by which I mean HTTP/XML in a RESTful manner) what should I be aware of and what should I be thinking of? I presume that this isn't a one size fits all thing so how do I choose which to use.
The two protocols have very different uses in the real world.
SOAP(using WSDL) is a heavy-weight XML standard that is centered around document passing. The advantage with this is that your requests and responses can be very well structured, and can even use a DTD. The downside is it is XML, and is very verbose. However, this is good if two parties need to have a strict contract(say for inter-bank communication). SOAP also lets you layer things like WS-Security on your documents. SOAP is generally transport-agnostic, meaning you don't necessarily need to use HTTP.
REST is very lightweight, and relies upon the HTTP standard to do it's work. It is great to get a useful web service up and running quickly. If you don't need a strict
API definition, this is the way to go. Most web services fall into this category. You can version your API so that updates to the API do not break it for people using old versions(as long as they specify a version). REST essentially requires HTTP, and is format-agnostic(meaning you can use XML, JSON, HTML, whatever).
Generally I use REST, because I don't need fancy WS-* features. SOAP is good though if you want computers to understand your webservice using a WSDL. REST specifications are generally human-readable only.
The following links provide useful information about WSDL vs REST including Pros and Cons
A couple of key points are that
1) SOAP was designed for a distributed computing environment where as REST was designed for a point to point environment.
2) WADL can be used to define the interface for REST services.
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl
Regarding WSDL (meaning "SOAP") as being "heavy-weight". Heavy matters how? If the toolset is doing all the "heavy lifting" for you, then why does it matter?
I have never yet needed to consume a complicated REST API. When I do, I expect I'll wish for a WSDL, which my tools will gladly convert into a set of proxy classes, so I can just call what appear to be methods. Instead, I suspect that in order to consume a non-trivial REST-based API, it will be necessary to write by hand a substantial amount of "light-weight" code.
Even when that's all done, you still will have translated human-readable documentation into code, with all the attendant risk that the humans read it wrong. Since WSDL is a machine-readable description of the service, it's much harder to "read it wrong".
Just a note: since this post, I have had the opportunity to work with a moderately complicated REST service. I did, indeed, wish for a WSDL or the equivalent, and I did, indeed, have to write a lot of code by hand. In fact, a substantial part of the development time was spent removing the code duplication of all the code that called different service operations "by hand".
This probably really belongs as comments in several of the above posts, but I don't yet have the rep to do that, so here goes.
I think it is interesting that a lot of the pros and cons often cited for SOAP and REST have (IMO) very little to do with the actual values or limits of the two technologies. Probably the most cited pro for REST is that it is "light-weight" or tends to be more "human readable". At one level this is certainly true, REST does have a lower barrier to entry - there is less required structure than SOAP (though I agree with those who have said that good tooling is largely the answer here - too bad much of the SOAP tooling is pretty dreadful).
Beyond that initial entry cost however, I think the REST impression comes from a combination of the form of the request URLs and the complexity of the data exchanged by most REST services. REST tends to encourage simpler, more human readable request URLs and the data tends to be more digestable as well. To what extent however are these inherent to REST and to what extent are they merely accidental. The simpler URL structure is a direct result of the architecture - but it could be equally well applied to SOAP based services. The more digestable data is more likely to be a result of the lack of any defined structure. This means you'd better keep your data formats simple or you are going to be in for a lot of work. So here SOAP's additional structure, which should be a benefit is actually enabling sloppy design and that sloppy design then gets used as a dig against the technology.
So for use in the exchange of structured data between computer systems I'm not sure that REST is inherently better than SOAP (or visa-versa), they are just different. I think the comparison above of REST vs SOAP to dynamic vs. static typing is a good one. Where dyanmic languages tend to run in to trouble is in long term maintenance and upkeep of a system (and by long term I'm not talking a year or 2, I'm talking 5 or 10). It will be interesting to see if REST runs into the same challenges over time. I tend to think it will so if I were building a distributed, information processing system I would gravitate to SOAP as the communication mechanism (also because of the tranmission and application protocol layering and flexibility that it affords as has been mentioned above).
In other places though REST seems more appropriate. AJAX between the client and its server (regardless of payload) is one major example. I don't have much care for the longevity of this type of connection and ease of use and flexibility are at a premimum. Similarly if I needed quick access to some external service and I didn't think I was going to care about the maintainability of the interaction over time (again I'm assuming this is where REST is going to end up costing me more, one way or another), then I might choose REST just so I could get in and out quickly.
Anyway, they are both viable technologies and depending on what tradeoffs you want to make for a given application they can serve you well (or poorly).
REST is not a protocol; It's an architectural style. Or a paradigm if you want. That means that it's a lot looser defined that SOAP is. For basic CRUD, you can lean on standard protocols such as Atompub, but for most services you'll have more commands than just that.
As a consumer, SOAP can be a blessing or a curse, depending on the language support. Since SOAP is very much modelled on a strictly typed system, it works best with statically typed languages. For a dynamic language it can easily become crufty and superfluous. In addition, the client-library support isn't that good outside the world of Java and .NET
To me we should be careful when we use the word web service. We should all the time specify if we are speaking of SOAP web service, REST web service or other kind of web services because we are speaking about different things here and people don't understand anymore if we named all of them web services.
Basically SOAP web services are very well established for years and they follow a strict specification that describe how to communicate with them based on the SOAP specification.
Now REST web services are a bit newer and basically looks like simpler because they are not using any communication protocol. Basically what you send and receive when you use a REST web service is plain XML. People like it because they can parse the xml the way they want without having to deal with a more sophisticated communication protocol like SOAP.
To me REST services are almost like if you would create a servlet instead of a SOAP web service. The servlet get data in and return data out. The format of the data are xml based. We can also imagine to use something else than xml if we want. For instance tags could be used instead of xml and that would be not REST anymore but something else (Could be even lighter in term of weight because xml is not light by nature). Would we call that still a web service? Yes we could but that will not follow any current standard and this is the main issue here if we start to call everything web services but we can do it the way we want then we are loosing on the interoperability side of the things. That means that the format of the data that is exchanged with the web service is not standardized anymore. That requires then that server and client agree on the format of the data whereas with SOAP this is all predefined already and server and client can interoperate without to know each other because they follow the same standard.
What people don't like with SOAP is that they have hard time to understand it and they cannot generate the queries manually. Computers can do that very well however so this is where we need to be clear: are web services queries and response supposed to be used directly by the end users or do we agree that web services are underneath API called by computer systems based on some normalized standards?
SOAP: It can be transported via SMTP also, means we can invoke the service using Email simple text format also
It needs additional framework/engine should be in web service consumer machine to convert SOAP message to respective objects structure in various languages.
REST: Now WSDL2.0 supports to describe REST web service also
We can use when you want to make your service as lightweight, example calling from mobile devices like cell phone, pda etc...
for enterprise systems in which your system is confined within your corporations, its easier and proper to use soap because you are almost in control of clients. it's easier since there a variety of tools which creates classes (proxies) and looks like you are doing your regular OOP which matches your java or .net environment (in which most corporates use).
I would use REST for internet facing applications for exposing interfaces (like twitter api) since clients can be using javascripts or html or others in which typing is not strict. REST being more liberal makes more sense.
Also for internet facing clients (world wide web), its easier to parse json or xml coming out of a rest interface rather than a purely xml coming from a soap interface. it's hard to use proxies on javascript and javascript does not naturally support objects. If you are using REST with javascript, you would just usually parse the json string and you're off. internet facing interfaces are usually very simple (so most of the time its simple parsing) and does not usually demand consistency that is why REST is adequate enough.
For enterprise applications I don't think REST is adequate because transactions, security, strict typing, schemas play a very important in enterprise applications development that is why SOAP is more suited for them.
My conclusion is that SOAP is for Enterprise systems, REST is for the Internet or WWW.
You can use it interchangeably but you may find yourself having a difficult time eventually not using the correct tool for the job.
sorry for my bad english.
In defence of REST it closely follows the principles of HTTP and addressability e.g. read operations use GET, update operations use POST etc. I find this to be a far cleaner approach. The Oreilly book RESTful Web Services explains this far better than I can, if you read it I think you would prefer the REST approach
The toolset on the client side would be one. And the familiarity with SOAP services the other. More and more services are going the RESTful route these days, and testing such services can be done with simple cURL examples.
Although, it's not all that difficult to implement both methods and allow for the widest utilization from clients.
If you need to pick one, I'd suggest REST, it's easier.
The previous answers contain a lot of information, but I think there is a philosophical difference that hasn't been pointed out. SOAP was the answer to "how to we create a modern, object-oriented, platform and protocol independent successor to RPC?". REST developed from the question, "how to we take the insights that made HTTP so successful for the web, and use them for distributed computing?"
SOAP is a about giving you tools to make distributed programming look like ... programming. REST tries to impose a style to simplify distributed interfaces, so that distributed resources can refer to each other like distributed html pages can refer to each other. One way it does that is attempt to (mostly) restrict operations to "CRUD" on resources (create, read, update, delete).
REST is still young -- although it is oriented towards "human readable" services, it doesn't rule out introspection services, etc. or automatic creation of proxies. However, these have not been standardized (as I write). SOAP gives you these things, but (IMHO) gives you "only" these things, whereas the style imposed by REST is already encouraging the spread of web services because of its simplicity. I would myself encourage newbie service providers to choose REST unless there are specific SOAP-provided features they need to use.
In my opinion, then, if you are implementing a "greenfield" API, and don't know that much about possible clients, I would choose REST as the style it encourages tends to help make interfaces comprehensible, and easy to develop to. If you know a lot about client and server, and there are specific SOAP tools that will make life easy for both, then I wouldn't be religious about REST, though.
You can easily transition your WSDL-spewing WCF web components to other uses just by changing your configuration settings. You can go across HTTP and then also named pipes, tcp, custom protocols, etc without having to change your code. I believe WCF components may also be easier to set up for stuff like security, two-way calling, transactions, concurrency, etc.
REST pretty much limits you to HTTP (which is fine in many cases).
I know that this discussion is an old one, but after reading all the answers and commented, I believe that everyone missed the most important point about the difference between the 2 systems: SOAP uses complex types to not only give you the data, but validate it and keep it in the strict type designation it was defined for. A WSDL tells you what the data format is, what the data type is, allows you to add reg-ex pattern-style rules, and defines how many times a piece of data must be, and may be, allowed in a request/response.
Rest on the other-hand has none of these mechanisms.
SOAP is complex and heavy because it allows you to send complex heavy hierarchical data. REST is plain text, with the origin and endpoint sorting out the rules.
SOAP is business independent, because it has all the data rules embedded in the document.
The difference between SOAP and REST is that SOAP is a self-contained business oriented schema. REST is a text document.
I have no experience with web services. Historically I've built client-server systems using proprietary communication protocols (even they happen to be XML). I just spent a few hours looking over Axis2 and it sent a shudder down my spine. The learning curve of WS scares me, and seeing all that XML surround so little functionality makes me wonder if it's worth the trouble.
How do you decide whether you need to use Web Services or a custom communication protocol? What are the advantages/disadvantages of each approach and what use-cases are they best suited for?
Please post a clear guideline, not an opinion piece :)
Build RESTful web APIs; then you get a lot of automatic caching and etc benefits that you don't get if you use other methods (SOAP, XML-RPC, etc)
See this post for more details
Another benefit is that if you build a RESTful API for your code to use, you can potentially let your users take advantage of it too - they often have uses for your product that you never dreamed of.
"Web Services" as defined by the W3C means using SOAP over HTTP. SOAP is severe overkill in most cases; it's only really appropriate (IMO) when you're making a public service available to the world, like an API for interacting with your website, for example.
Anything else (especially internal, private communications) rarely need anything more complex than XML-RPC. Only if performance is an issue should you consider a more condensed protocol; XML-RPC is so simple and widely-supported that the ease of development and debugging more than makes up for the performance loss of using bloaty ol' XML.
Remember that there are a number of frameworks out there that make programming web services very trivial stuff. In the VB / C# world .Net makes it a joy. I'm not really sure about specific frameworks for other languages but I am sure most have at least one.
The standardisation and simplicity of implementation and reuse of web services make them very attractive. As previously pointed out- yes, they make communications very verbose. If you are worried about this why not calculate how much data you actually will be trasmitting. chances are, with current network and internet speeds, it will be trivial - even with the XML overhead.
I would always use the custom data formats as a last resort and not a first. What widely used method you use it up to you but it's unlikely you would go wrong with Web Services model.
Maintainability and extensibility are the main benefits. The use of widely used technology your solution will be easier for someone else to understand plus you can use ready to roll libraries as consumers and providers.
I have recently broken my custom protocol habit. I am now using Apache on the server side and libCurl plus libxml2 to load and parse the XML on the client which is written in C++.
The server side can be either PHP or a CGI written in a more serious language. Depends what you want to do.
Webservices have the advantage of being somewhat standard, so it's possible for programs you've never heard of to use a webservice you wrote. Using HTTP can help them communicate over proxies and other network obstacles without any extra work from you. The XML, although rather verbose and ugly, is rather easier to read when debugging than binary data.
When you're transferring stuff over the network, it's unlikely that serialisation/deserialisation to xml will be the limiting factor in performance. It can be a bit of hassle, although a library to do it for you will help a lot.
SOAP and XML -- "all that XML surround so little functionality makes me wonder if it's worth the trouble."
Totally. SOAP is heavy-weight, and -- to a large extent -- a workaround to the need for static binding throughout the Java technology stack.
REST, on the other hand, is much lighter weight. Further, REST with JSON or REST with YAML is very lightweight, and very easy to implement. It builds right on top of the off-the shelf HTTP protocol.
REST requires you to define resources (named via URI's), and transactions based on the canonical CRUD rules (GET, POST, PUT and DELETE). Very simple and canonical.
In my personal (old cranky dude) opinion, web services should only be used as a way to make some of your internal information available to third parties (i.e. other companies, people outside your organization etc.). Of course, that is also the originally intended purpose of XML. :-)
If you have access to a direct connection with the databases containing the information your application needs - that is the way to go. It's faster and simpler - which in application development means "better" and "less buggy".