I know this is an old question and must have been answered hundred times already, but I am not able to find a satisfactory response as yet.
I am creating an application which will be used by other applications (mobile/ web) to fetch the data. Now I have 2 options:
- Create my application as a simple web application.
- Create a web service.
A web service looks more sophisticated where any client will provide the data in a specified format (SOAP/ REST) and my app will parse the request and return the data asked by client. How the data will be used is not my app's problem.
My question is that same can be achieved by a simple web app accepting the request in XML format and responding with an XML response. Gut feeling is that a web service will be a better way to go for this kind of service where we are not sure who all will be using it. But are there any specific advantages of using a web service over a simple web app?
Web services dont always have a UI. They are normally API's using JSON, can also be SOA type using SOAP and XML primarily, can also be sockets, and servers and other micro web services, etc..
Web applications can be put together many ways. There are several ways to create your application by orchestration of multiple web services, and a separate gui to control them which ties into these services. The other way which does not use services is to procedurally embed code into your UI interface app, or even better, make an Object Oriented application which has its own services separed in the Model later, which the controller access, and has its own view as a GUI which access the services in the back end, or even more complicated apps that pass A2B, B2B, B2C services from some GUI.
Services dont always have a GUI, they can have a CRUD to maintain the data, but once you start to have these types of features, it becomes an application in its own right. The services are applied to something greater than themselves. this applying creates your application. It has to have a purpose. Normally it takes more than one blind service to complete your applicatoin, and there is some kind of interface.
If you just blindly send a uri request to your service, and it blindly sends back json, that's a service. Whats blindly sending this? If you, then not an application. If some sort of crud, then its becoming an application, the crud is a GUI for accessing the services, and as a whole, its a data management application system. Now if you put a layer on the front to demonstrate this data in website fashion, you now have a product to display this data, a product to manage it, and the data which is the real product, and which is accessible via the web service, its now a full on application. Your endeavour at creating this becomes your application.
I asked this question more than 3 yeas back and a lot of water has flowed under the bridge since then. I have worked on tens of web applications and created hundreds of web services. So I guess it makes sense to answer my own question here.
The challenge which I faced when I asked this question was that I got confused between the terms application and service (note that web is common element in web application and web service). As the name would suggest, application is an application in itself, whereas a service is meant to serve others. A service probably has no meaning unless someone is going to use it. It can serve one or more applications or services.
Now if I look at my question
I would like to tell myself that "Dude! if there is an entity which takes a request and returns data, you are talking about a service." Because I am not worried about what is going to happen with that data? Who will use it? How will that be displayed?
I am taking a request and returning data. Now how am I doing that is part of implementation. I might use SOAP or REST. I might use Jersey or Spring MVC/ REST or may be a simple servlet which takes a request and returns data in JSON or XML or String or any other required format.
That is a web service. I think this is an issue of terminology. You have no way of solving this other than to use a web service, whether it is restful or SOAP based is up to you but if you are passing data to clients in XML format, in response to XML requests, that is a web service.
I suspect what you mean to ask is whether or not you should be using a RESTful webservice or a complicated SOAP based approach. For me the answer depends on how many functions are needed in your 'Service'.
SOAP
If your service has lots of functions than users of java and/or visual studio would prefer to import your WSDL file and use your service as an object with all of the XML parsing done for them, so SOAP would be the answer.
REST
If you only have a few functions, with very basic input parameters and response data, then SOAP might be overkill.
or
or
I know its too late to replay, but still i want
Web Services approach is good if
a. enterprise integration with only webservices, like integrating distributed modules /applications.
b. suited for distributed applications
c. more than one consumer for same service - like Banks consuming data from Credit Reporting Agency
d. consumers want data in different formats - like one consumer(customer) wants in XML format, other would be in JASON ..etc
I guess the web application vs web service is the fact that the deployment factor ratio vary meaning the deployment of a web application would be limited (locally ) to what as in case of a web service (globally). Plus, When we think of UI perspective better option is the Web application but when we think of programming and data transfer perspective mainly go for a web service. Web application requires use of servlets with frameworks like Spring mvc etc. On the other hand, if you want to deploy the same application to multiple platforms make it a web service via Rest/Soap implementations so that the web applications behaviour gets changed to rather a service.
In short,
From RESTful Web Services by Leonard Richardson and Sam Ruby, ISBN: 978-0-596-52926-0: