Web Service vs Web Application

问题:

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:

1. Create my application as a simple web application.
2. 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?

回答1:

At a low level web applications and web services are kinda the same thing. They both operatate over http(s). SOAP is just a well defined version of XML. REST is kinda just HTTP. If you wanted to, you could make a web application look like web services and visa versa.

The main difference would be internal development options based on the platform you are using. If, for example, you are using Visual Studio then adding a WCF Service Application will give you a project which is by default geared towards WCF. But choosing any other application type won't stop you from adding Web Services.

Using SOAP is generally a better option than plain old xml for these reasons:

• Your users will be expecting it, and are likely to know how to read it already.

• Your users' development environments will likely know all about SOAP and be able to interpret it out of the box. (If you provide a WSDL file then many users will be able to use a script to generate your classes in seconds.)

• Your messages are more likely to be well defined. I am working on a project at the moment where the other side have defined their own random XML structure and it is a nightmare to work with. I never really know what to expect, and there is little consistency between their different message types. At least if they had agreed to conform to SOAP then I might have had a much easier time interpreting their messages.

回答2:

If we think the terminology, which I think is the main question here.

Web service refers to software, that serves data in any format (XML/JSON etc.) through some kind of web interface. That interface can be called API (Application Programming Interface). REST and SOAP are ways to design the API.

Application is the software that is using this API provided by the web service.

In the other words, web service is "server" and application is "client". Usually server serves machines and clients serve the user.

So in any way you choose to build your system, I would call the part that serves the data as "Web service" and the part that utilizes the data as "application" (or "web application" if such).

Sounds like in your case, you are building a web service that provides XML-formatted data for multiple applications. So my answer is: build the thing you are already building and call it web service.

回答3:

If your application doesn't need a user interface, then make it a web service. If it needs a user interface, then use a web application.

回答4:

I think this might help you in resolving your confusion

There are two main use cases of WEB in the industry

1. Business to Consumer(B2C) : Whenever there is consumer directly interacting with the business for its needs we always uses a Web-Application to provide a communication between two parties.
2. Business to Business(B2B) : It means one part of the business need some input/services from another part of the business. Always a Web-Service is used to meet the business to business requirements. Usually a consumer never interact with the Web-Services directly we only interacts with a Web-Application and a Web-Application interact with a Web-Services for information/data or processing.

Taken from http://coder2design.com/java-interview-questions/

回答5:

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.

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.

MySite.com/Add/5/3

or

MySite.com/GetStockSymbol/Facebook

or

MySite.com/GetWeather/Paris/France

回答6:

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 am creating an application which will be used by other applications (mobile/ web) to fetch the data. Now I have 2 options, 1. to create my application as a simple web application 2. To create a web service.

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.

回答7:

From RESTful Web Services by Leonard Richardson and Sam Ruby, ISBN: 978-0-596-52926-0:

Web services are indeed very similar to web applications, but resource creation is one of the places where they differ. The main difference here is that HTML forms currently support only GET and POST. This means web applications must use overloaded POST to convey any unsafe operation.

回答8:

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

回答9:

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.

回答10:

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,

   WebService   =

                 (RestApi/Soap)    # added 
             /         |         \
(client1)---(Web Application)---(clientN)