• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why should one use web service

 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Recently, I did some small work for a friend which involved data exchange with a client over HTTP.
The server side component was a servlet.
The client was an Android phone.
Data was exchanged as JSON over HTTP post.
Simple and straight forward.

All of this got me thinking, what are the scenarios where it is a smart choice to go for web services? What kind of problems, can be solved only by web services?
 
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's my take on this.

I feel the biggest value that SOAP and REST compliant interfaces - what we typically mean when we say "web services" - is that they are
self documenting. They don't solve any technical problems as much as they solve human communication problems.

You could call your adhoc HTTP API a web service, and you wouldn't be wrong.
But it's not self documenting. For example, imagine a dozen new companies come to you showing an interest in your server's functionality:
- How do they know the URLs of your interface?
- How do they know what parameters your inteface takes?
- What are the valid values for those parameters?
- In what format are errors received?
- Does your interface update server state, or does it only retrieve information?
- How is the dev supposed to authenticate to your interface?
- What is the backward compatibility of the newest version of your interface?
- Can your interface participate in a transaction?

The simplest answer would be that they ask you and you tell them.
Perhaps over email or phone, or better still via good developer documentation.

But then you decide to upgrade your functionality or authentication or other aspect.
Now what? Will you call all dozen of them back and update them orally?
Or tell them the docs are updated and ask them to change their code?

There's a communication problem here, and the risk of miscommunications.

The companies behind SOAP addressed all such questions using a combination of standards.
There were standards for the WSDL language which specified the functionality, parameters, valid values and endpoints.
There were standards like WS-Security for authentication and authorization, WS-Transaction for supporting transactions, and more.

But then they kind of overdid it. The WS-* are probably the best example for this explosion of standards and standards body politics.
Nonetheless, they did solve a communication problem.

The alternative RESTful approach solved some of these communication problems too, but in a different and incomplete way.
It didn't come up with any new concept; it just added new meaning to existing HTTP concepts and imposed constraints on when they could be used.

So anything offered by a service was categorized into one or more resources. The HTTP GET verb was supposed to be used only for idempotent
read ops, PUT only for creation, POST only for updation, DELETE for deletion.
What was not self documenting was the list of available resources and the meanings of parameters, but once that was provided, the operations
on them were self documenting.
REST did not offer any standards for all the other aspects like authentication or transactions. As far as REST was concerned, each aspect was just
another resource.

SOAP was complicated and often not supported by the scripting languages like PHP, javascript, and perl which were popular among web companies.
REST was simple enough to implement for web startups, who wanted to expose a public API but who didn't want to and usually didn't need to
contend with the complexities of WS-* standards. That said, REST is sometimes too restrictive and I don't think anybody is comfortable using them without developer docs.

So, as I see it, web services solve the communication problems inherent when a service grows to a point where it has a large number of diverse
external developer teams wanting to use it. If it's an interface between one client and one server and the 2 devs are buddies, web services are overkill

--------------------------
Side note:
SOAP added obvious value back in the 90s and 00s when multiple languages were being used in different companies, and clients had to integrate multiple systems from multiple vendors.
An interface definition based on text based XML transported over HTTP and following defined standards, was far better for interoperability than all the binary interfaces like Corba, RMI, DCOM
which couldn't be used by web languages like PHP and JS.
Since you are already using HTTP, I read this question as "when to use SOAP/REST compliant HTTP and not adhoc HTTP", and hence the above answer.
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow! I had not even thought on these lines. Awesome!
I think you deserve a cow for this Karthik! Moo!
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the cow, Maneesh!

If people want to work deeply with SOAP web services, one vertical with lots of opportunities, now and in future, is telecom.

I worked in a mobile telco vendor company for a few years. Mobile providers - think Airtel, Vodafone, etc - tend to buy a diverse set of networking equipment from multiple vendors.
We're talking about thousands of network switches and servers, sourced from around a dozen vendors.
All developed using different language stacks, running different OSes, talking different protocols.

But though the vendors are many, the provider's operations personnel obviously need a unified view of the entire network to manage it.
So they all had to be integrated using a merry mix of probably ~200-300 CORBA interfaces and web service interfaces, usually the SOAPy kind.
Inspite of using CORBA IDL, WS standards and WSDL, there were quite often confusions over interpretation of some value or parameter or behaviour.
Almost always, it required clarification from the other company's contact persons.

REST or adhoc APIs in that kind of a complex integration environment would have been an utter disaster.
SOAP, despite all the flak it gets for being overengineered, still has its legitimate uses!
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic