Introduction to Middleware: Web Services, Object Components, and Cloud Computing by Letha Hughes Etzkorn

Author:Letha Hughes Etzkorn [Etzkorn, Letha Hughes]
Language: eng
Format: azw3
ISBN: 9781351632782
Publisher: CRC Press
Published: 2017-06-12T04:00:00+00:00

10 Non-RESTful Web Services

10.1 JUST WHAT DO WE MEAN BY “NON-RESTFUL WEB SERVICES,” ANYWAY?

As we saw earlier in Section 9.2, there are some differences of opinion as to what “RESTful” and “non-RESTful” mean. Ignoring “RESTful” for now, let’s briefly re-examine what “non-RESTful” means.

Let’s start with the common definition that a “non-RESTful web service” defines a remote procedure call using a specifically defined interface, where this remote procedure call treats the HTTP protocol as a transparent lower networking layer (it doesn’t have to know anything about HTTP, it just assumes it’s there and it works), and uses the SOAP messaging protocol (we will see SOAP in Section 10.2) that includes an XML-type data format. This definition is fairly widely accepted in the industry.

However, this is not a totally clear definition. For example, a web service that uses Web Services Description Language (WSDL) to define the interface (we will see WSDL in Section 10.3), which commonly employs SOAP, would be considered “non-RESTful” by this definition. However, it is possible to configure a WSDL interface that runs directly using HTTP (in which case it could be called RESTful). It’s also possible to define a WSDL interface that runs on top of TCP and bypasses HTTP altogether—in this case the data would be sent in binary, and would normally not be considered either RESTful or non-RESTful.

Also, it’s possible to have a remote procedure call and use SOAP, but have the data sent directly over TCP—we saw this earlier in .Net Remoting. But .Net Remoting is not a web service, but rather is object-oriented. So we’re making some very small distinctions here.

However, since it’s a common definition, even though there are problems with it, we will use this definition.

There are several advantages to requiring a well-defined remote procedure call-type interface. For one thing, the interface is documented to a certain degree, particularly if you’re using WSDL. That is, you can read the name of the remote procedure, the names of the parameters to the remote procedure. You can read the types of the parameters and the return type. What you don’t get, unfortunately, is any real description, at least in the interface description itself, about the purpose of any of these items. This can be very important, especially in a very large (perhaps enterprise-wide) application that is created with a service-oriented architecture, in that at least a minimum level of documentation is required. (In an HTTP-only interface [an example of a RESTful interface] not even that much description is specifically required by the interface itself.)

The other big advantage of a well-defined remote procedure call-type interface is that clients can, in many situations, automatically read the interface and automatically configure themselves (or be configured automatically) to call that interface correctly.

Okay, now we know generally what we’re talking about. In the sections below, we’re going to discuss multiple technologies related to non-RESTful web services. We’re going to start with SOAP, which is an enabling technology. Then we will discuss WSDL, which is used one way or another in various implementations of non-RESTful web services.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.