Web service: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Pat Palmer
(linking to External Links)
mNo edit summary
 
(24 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{subpages}}
{{subpages}}


A '''web service''' is a broad term encompassing a variety of client-server approaches to distributing software across a network. Since around 2000, the term has been used predominantly to refer to two distinct ways by which computer programs can request information from remote computers, web services with [[SOAP]] and web services with [[REST]]. 
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.
The two approaches grew up simultaneously from different groups.  Although a long and vitriolic debate about the merits of the two approaches was fought in internet blogs and articles from 2004 until 2008, the approaches are really quite different, with each being useful under the right conditions.


SOAP-based web services publish a formally defined service contract described in a machine-processable format ([[WSDL]], a form of [[XML]]), and the SOAP protocol (riding on top of TCP) uses XML as the messaging "wire format" between client and server.  For some examples, see the U. S. Geological Survey ([[USGS]]) page (see [[Web_service/External_Links]]).
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.


REST-based web services use [[TCP]].  The request "wire format" is a TCP GET command, parameters are appended to the URL, returned data can be in a variety of text-based formats, and there is no standard for formally publishing a service contract.  A well-known example of the REST web service is the Google Maps API (see [[Web_service/External_Links]]).
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.


==History==
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.]
As soon as there were programming languages, computer programmers have desired to reuse certain programs to avoid "reinventing the wheel".  One of the ways people envisioned reusing software was to provide libraries of code which could be called by other programmers.  Ever since the advent of the internet, programmers sought ways to call the code in libraries from remote host computers.  But such remote calling was difficult because there were many different types of computer hardware and operating systems, each of which stored and processed data in very different ways.   


In the 1980's, people used the [[C programming language]] to make [[Remote Procedure Calls]] from one computer to another across the internet.  But such RPC programming, or "sockets programming" as it was sometimes called, was cumbersome and difficult to achieve.  And it was especially difficult when the two endpoints of the connection were on different hardware or operating systems.
[[Category:Suggestion Bot Tag]]
 
A second, related goal was to achieve electronic commerce.  People desired to place orders on their local computer have the orders transmitted electronically to remote computers, perhaps located in different companies, for fulfillment.  This led to an effort called Electronic Data Interchange (EDI), which attempted to define messaging CORfor such exchanges of orders.  The messaging style used in the 1980's was ASN.1 (Abstract Syntax Notation), which was complex and difficult to work with.
 
In the 1990's, Microsoft Windows introduced new technologies for creating remotely callable libraries across a network.  [[COM]], [[COM+]], and [[DCOM]] were successive generations of the Microsoft technology, and these kinds of remote libraries could be created and deployed rapidly if both endpoint computers were running Microsoft Windows.  In response to the growing success of COM on Windows, the UNIX world (led by Sun Microsystems) created a consortium, Open Management Group (OMG), that defined CORBA as a remote calling technology for UNIX and Linux.  CORBA and COM competed heavily throughout the 1990's.
 
Then in 1998, the [[XML]] standard emerged.  XML messages, which consist of only plain text (no binary strings), are not blocked by firewalls.  Also, all the leading programming languages and operating systems quickly developed software tools to parse XML.  So XML became the new way to package information for shipping across a network.
 
In 2000, Microsoft began quietly leading an industry consortium to define a standardized way of using XML for messaging in remote procedure calls.  This consortium resulted in the [[SOAP]] standard.  SOAP is a special form of XML that can be used for RPC's.  When a called on a local computer wished to invoke a library on a remote computer, the name of the procedure being called and any parameters for the call must be "serialized" into a SOAP message.  The SOAP (XML) message is shipped across the network to the library, which "deserializes" the SOAP message, executes the call, prepares the results, and then "serializes" the results into SOAP.  The SOAP result is shipped back across the network to the caller, where it is then "deserialized". 
 
With the .NET platform in 2002, Microsoft introduced early implementation of several standards related to using SOAP messaging in remote procedure calls.  Most importantly, Microsoft provided automation for creating proxy objects.  Proxies are procedures that seem to be on the local computer, and programmers call them just as if there were local.  But in reality, when a proxy is called, it serializes the request and sends it to a remote computer, awaits the response and deserializes it, and then responds to the caller.  The caller need not even be aware that a remote call is being made.
 
Key to proxy automation is that each remote procedure's "contract" is first published permanently on the web as an XML document.  The standard for describing how to call a SOAP-based remote procedure is WSDL (Web Services Description Language).  Microsoft's Visual Studio .NET, beginning in 2002, allowed programmers to create procedures and annotate them with a "WebMethod" attribute.  The presence of this attribute meant that the .NET compiler would automatically create the WSDL document for the programmer.  Thus it was very easy to create a callable SOAP-based web service.  Likewise, Visual Studio .NET automated the creation of a proxy on the client side; calling a SOAP-based web service required only that the programmer add a "web reference" in her project, by giving Visual Studio the URL of the WSDL document describing the procedure to be called.  After that, the remote procedure (a so-called SOAP-based web service) could be invoked as if it were local.
 
No sooner had programmers begun extensively using SOAP-based web services, than what appeared to be an alternative was proposed, so-called REST-based web services.  Since 2000, a vigorous and often impolite debate has been waged among developers on the internet, full of zealotry for each technology.  As with any competing technologies, there are good reasons to use either one in certain circumstances.
 
==Citations and References==
* [http://www.w3.org/TR/ws-arch/#whatis '''W3C''']

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  [?]
 
https://en.citizendium.org/wiki/index.php?title=Web_service&printable=yes
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.]

Retrieved from "https://citizendium.org/wiki/index.php?title=Web_service&oldid=993622"