Web service: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Pat Palmer
mNo edit summary
mNo edit summary
 
(6 intermediate revisions by one other user not shown)
Line 3: Line 3:
A '''web service''' is a broad term referring to various ''[[Client-server|client-server]]'' approaches to distributing software across a network. More narrowly, a web service is a program addressable by a [[URL]] on a [[web server]], which can be invoked from a client machine elsewhere on the network.  Conceptually, a web service may be regarded as an [[application programming interface]] (API) distributed across a network and callable by the client without regard for the underlying operating system on which the web service runs.
A '''web service''' is a broad term referring to various ''[[Client-server|client-server]]'' approaches to distributing software across a network. More narrowly, a web service is a program addressable by a [[URL]] on a [[web server]], which can be invoked from a client machine elsewhere on the network.  Conceptually, a web service may be regarded as an [[application programming interface]] (API) distributed across a network and callable by the client without regard for the underlying operating system on which the web service runs.


As early as the mid-1990's, people were using the [[HTTP]] protocol to call programs remotely across the internet.  [[CGI]] technology and web server [[scripting languages]] such as [[Perl]] were used to return dynamically-constructed web pages to a browser for consumption by human readers.  Requests to such server programs could be modified by including parameters in the URL of the HTTP [[GET request]] message, and the response sent back was a web page, an image, or another [[MIME type]] that can be handled by the world wide web.  This kind of internet-based program invocation has, somewhat inaccurately, come to be called REST (REspresentational State Transfer).  The term REST, coined from the Ph. D. dissertation of [[Roy Fielding]], theoretically does not apply to all HTTP GET requests, but in practice, the public has used it as such despite Dr. Fielding's protests to the extent that ''REST web services'' now tends to apply to any API that is implemented using HTTP GET requests, whether or not the API actually meets Dr. Fielding's arguably difficult-to-understand set of constraints.
As early as the mid-1990's, people were using the [[HTTP]] protocol to call programs remotely across the internet.  [[CGI]] technology and web server [[scripting languages]] such as [[Perl]] were used to return dynamically-constructed web pages to a browser for consumption by human readers.  Requests to such server programs could be modified by including parameters in the URL of the HTTP [[GET request]] message, and the response sent back was a web page, an image, or another [[MIME type]] that can be handled by the world wide web.  This kind of internet-based program invocation has, somewhat inaccurately, come to be called [[REST]] (REspresentational State Transfer).  The term REST, coined from the Ph. D. dissertation of [[Roy Fielding]], theoretically does not apply to all HTTP GET requests.  But in practice, the term ''REST web service'' now tends to apply to any API that is implemented using HTTP requests alone (whether GET or POST), in which each individual resource is assigned a unique URL.


A completely different kind of ''web service'' grew up in parallel with REST web services, in which a client ''program'' calls a server program by sending, not an HTTP request, but a SOAP request, and receiving a SOAP response.  SOAP is a messaging protocol which typically rides on top of HTTP and uses [[XML]] for its message format.  SOAP provides error handling and other capabilities beyond those of HTTP alone.  Today, most major programming languages provide automated support for SOAP messaging, so that programmers can invoke remote SOAP web services almost exactly as if the web service resided locally on the client machine.   
A completely different kind of ''web service'' grew up in parallel with REST web services, in which a client ''program'' calls a server program by sending, not an HTTP request, but a [[SOAP]] request, and receiving a SOAP response.  This kind of web service may also be viewed as a [[Remote Procedure Call]] (RPC).  SOAP is a messaging protocol which typically rides on top of HTTP and uses [[XML]] for its message format.  SOAP provides error handling and other capabilities beyond those of HTTP alone.  Today, most major programming languages provide automated support for SOAP messaging, so that programmers can invoke remote SOAP web services almost exactly as if the web service resided locally on the client machine.   


During the years 2002 until around 2008, a vigorous dispute arose in blogs and discussion groups on the internet about the efficacy of REST vs. SOAP web services.  The two camps arose simultaneously from different cultures and using largely different software tools.  The ensuing verbal firestorm was arguably fed by certain companies with commercial interests in the success or failure of either REST or SOAP.  It was further exascerbated by a grandiose, much-hyped vision for [[SOA|Service Oriented Architecture]] (SOA) which, however, failed to come to fruition.  Eventually, as tools support for SOAP became better, an equilibrium of opinion was reached in which both REST and SOAP web services are correctly valued in the appropriate setting and both are well-supported by all the major programming languages.  [NOTE: Cite Gartner Research hype cycles here.]
During the years 2002 until around 2008, a vigorous dispute arose in blogs and discussion groups on the internet about the efficacy of REST vs. SOAP web services.  The two camps arose simultaneously from different cultures and using largely different software tools.  The ensuing verbal firestorm was arguably fed by certain companies with commercial interests in the success or failure of either REST or SOAP.  It was further exascerbated by a grandiose, much-hyped vision for [[SOA|Service Oriented Architecture]] (SOA) which, however, failed to come to fruition.  Eventually, as tools support for SOAP became better, an equilibrium of opinion was reached in which both REST and SOAP web services are correctly valued in the appropriate setting and both are well-supported by all the major programming languages.  [NOTE: Need to cite (Faulkner?) hype cycles here.]
 
[[Category:Suggestion Bot Tag]]

Latest revision as of 07:01, 7 November 2024

This article is developing and not approved.
Main Article
Discussion
Definition [?]
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

A web service is a broad term referring to various client-server approaches to distributing software across a network. More narrowly, a web service is a program addressable by a URL on a web server, which can be invoked from a client machine elsewhere on the network. Conceptually, a web service may be regarded as an application programming interface (API) distributed across a network and callable by the client without regard for the underlying operating system on which the web service runs.

As early as the mid-1990's, people were using the HTTP protocol to call programs remotely across the internet. CGI technology and web server scripting languages such as Perl were used to return dynamically-constructed web pages to a browser for consumption by human readers. Requests to such server programs could be modified by including parameters in the URL of the HTTP GET request message, and the response sent back was a web page, an image, or another MIME type that can be handled by the world wide web. This kind of internet-based program invocation has, somewhat inaccurately, come to be called REST (REspresentational State Transfer). The term REST, coined from the Ph. D. dissertation of Roy Fielding, theoretically does not apply to all HTTP GET requests. But in practice, the term REST web service now tends to apply to any API that is implemented using HTTP requests alone (whether GET or POST), in which each individual resource is assigned a unique URL.

A completely different kind of web service grew up in parallel with REST web services, in which a client program calls a server program by sending, not an HTTP request, but a SOAP request, and receiving a SOAP response. This kind of web service may also be viewed as a Remote Procedure Call (RPC). SOAP is a messaging protocol which typically rides on top of HTTP and uses XML for its message format. SOAP provides error handling and other capabilities beyond those of HTTP alone. Today, most major programming languages provide automated support for SOAP messaging, so that programmers can invoke remote SOAP web services almost exactly as if the web service resided locally on the client machine.

During the years 2002 until around 2008, a vigorous dispute arose in blogs and discussion groups on the internet about the efficacy of REST vs. SOAP web services. The two camps arose simultaneously from different cultures and using largely different software tools. The ensuing verbal firestorm was arguably fed by certain companies with commercial interests in the success or failure of either REST or SOAP. It was further exascerbated by a grandiose, much-hyped vision for Service Oriented Architecture (SOA) which, however, failed to come to fruition. Eventually, as tools support for SOAP became better, an equilibrium of opinion was reached in which both REST and SOAP web services are correctly valued in the appropriate setting and both are well-supported by all the major programming languages. [NOTE: Need to cite (Faulkner?) hype cycles here.]