Second Generation Web Services
by Paul Prescod
|
Pages: 1, 2, 3
The Role of HTTP
You may notice a recurring theme. Everything that we want to do in this web service is already supported in HTTP. The only things that we need to create are XML vocabularies. And that was the whole point of XML: to focus on data interchange instead of software components.
Everything in UDDI can be represented in terms of HTTP operations on XML resources. So HTTP isn't accidentally paired with URIs as one of the central technologies of the Web. It is designed specifically as a major part of the identity-centric REST architecture.
Here's the radical idea: no matter what your problem, you can and should think about it as a data resource manipulation problem rather than as an API design problem. Think of your web server as this big information repository, like a database. You are doing data manipulation operations on it.
In discussing UDDI I've chosen a web service that is ripe for an easy conversion to REST philosophy, but we can apply these principles to anything. What about something like a purchase order submission? That seems more transactional. Well, purchase orders want to be named also. If you POST or PUT a purchase order to a new URI then internal systems all over your company can instantly refer to it no matter where they are. Using HTTP, an arbitrary XSLT stylesheet or Perl script sitting on an employee's desktop in the Beijing office can massage data from a purchase order sitting on the accounting mainframe in Los Angeles. Accessing HTTP-addressable resources is no more difficult than accessing files in local file system, but it requires much less coordination than standard file system sharing technologies.
Even web services with complicated work flows can be organized in a URI-centric manner. Consider a system that creates airline reservations. In a traditional HTML system there are a variety of pages representing the different stages in the logical transaction. First you look up appropriate flights. You get back a URI representing the set of appropriate flights. Then you choose a flight. You get back a URI representing your choice. Then you decide to commit. You get back a web page that returns reservation number. Ideally the URI for that page will persist for a reasonable amount of time so that you can bookmark it. You can think about any business problem in this way.
HTTP can easily be used even for peer-to-peer, asynchronous, and reliable distributed computing. I'd write out how to do so in the margin, but there is no room. In the meantime, check out the references at the end of the article.
An XML-based web service could go through the exact same steps. Rather than returning HTML forms at each step, the service would return XML documents conforming to a standard airline industry vocabulary. Those same XML documents could be used on a completely different airline reservation site to drive exactly the same process.
Summary: Any business problem can be thought of as a data resource manipulation problem and HTTP is a data resource manipulation protocol.
Security
Making your data universally addressable is not equivalent to making it universally accessible. It is easy to hide objects by merely never publishing their URIs. It is also easy to apply security policies to objects. In fact, REST simplifies security greatly.
Under the SOAP RPC model, the objects that you work with are implicit and their names are hidden in method parameters. Therefore you need to invent a new security strategy for each and every web service. UDDI is completely unlike .NET My Service which will likely be completely unlike Liberty and so forth. Under REST, you can apply the four basic permissions to each data object: GET permission, PUT permission, DELETE permission, and POST permission. You might also want to allow or disallow GET, PUT, DELETE, and POST on sub-resources. This model is exactly like the one used for today's file systems. It is proven and it works. I know of no security model that works in a similarly generic manner for remote procedure call models.
Resource-centric web services are inherently firewall friendly because they use GET to mean GET, PUT to mean PUT, and so forth. A firewall admin could easily make a web service read-only by blocking HTTP requests using anything other than GETs.
Maintenance
In fact, security is just one form of maintainability that is simplified by REST. Any network administrator will tell you that every level of networking causes its own headaches. Some days IP works but DNS doesn't (DNS server goes down or DNS settings misconfigured). Some days IP and DNS work but HTTP doesn't (the firewall or proxy misconfigured). If you run a web service protocol on top of HTTP it will add its own layer of configuration and software headaches on top of the existing ones. It is just one more thing to go wrong and one more place for security holes to slip through.
Once you have your service working, it is usually possible to "test" REST web services just by looking at them in a browser. Even complex multi-step services can be tested through HTML forms which generate HTML forms which generate HTML forms. QA departments will rejoice! Standard tools can monitor service availability. In essence, testing REST web services is like testing web sites. On the other hand, every SOAP RPC service will have its own security model, its own addressing model, an implicit data model, an implicit state-transition chart, and its own set of methods. Testing such a system is much more challenging.
The Rest of the Story
This brief introduction can only whet your appetite to the theory and practice of REST-based web services. In an upcoming article, I will
- describe in more detail how any web service can be transformed into a URI-centric one;
- show an example of a successful, public, widely used web service that uses this model today;
- discuss the role of SOAP in these sorts of web services;
- discuss reliability, coordination, transactions, asynchronicity, firewalls etc.
If you would like to learn more in the meantime, please consider visiting the REST-wiki and the REST mailing list. Discussion, even confrontation with REST advocates will clarify our thoughts and perhaps convince you that this model is not as crazy as it seems.
Does the REST model make sense, or is SOAP enabling something that couldn't have happened otherwise?
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- WEB Developer
2008-01-12 22:38:07 WEBDeveloper [Reply]
Want to become a web developer?
" http://www.masterinweb.com (http://www.masterinweb.com)
The web developers choice.
- WEB Developer
2008-01-12 22:36:48 WEBDeveloper [Reply]
Want to become a web developer?
http://www.masterinweb.com
The web developers choice.
- Waht abt other transports?
2007-08-13 02:39:27 deepakkm [Reply]
This is absolutely true if we are thinking only on http as the transport. But what about the transports like JMS, Jabber etc. As per this philosophy each transport should look for its native protocol for the service. I think a good architecture should be agnostic to its lower layer. In a SOAP service you can invoke it in a similar way irrespective of the underlaying transport. Also I cannot agree that web service is only meant for HTTP. Most of the asynchronous services are built over JMS.
- RPC's are not the issue
2003-05-02 21:29:46 David Forslund [Reply]
I disagree with the statement of this paper that the failure of DCOM/CORBA/RMI was that they have an RPC model. DNS relies on RPC's and works just fine on the scale of the Internet. SOAP relies on RPC's, just a smaller set of RPC's. RPC's don't have to be synchronous and don't have to be in CORBA either. SOAP works because it is dealing with much less complicated problems than are done with CORBA and does so with much greater complexity. The main valid argument with CORBA is the relative inflexibility of the IDL (no versioning, etc.), but this is a relatively easy to deal with issue. CORBA has worked very well in enterprises for many years and also works quite well on the internet with full cross-vendor and platform interoperability.
Basing next generation distributed computing on http, xml and uris is a serious limitation although it does make some things simpler. It also isn't reasonable to compare CORBA, DCOM, and RMI since they differen considerably in terms of interoperability, platform independence, and language independence. XML is great but adds a great deal of complexity compared to full object-oriented techniques which are excellent at dealing with complex problems.
Check out http://www.zeroc.com for a good technical alternative to CORBA/DCOM etc, that actually works and builds on the best we have learned from past experiences. I have no connection to that work, but I think it is very well designed.
- I see a whole lot more work than REST.
2002-03-19 06:01:42 Walter Dyer [Reply]
It's a beautiful thing, but just a step along the way. We'll need REST to allow us the ability to develop common objects. But what will we need to develop common business processes? What type of repository will be necessary to store these processes? Who will own the authoritative data source(ADS) and get paid a quarter cent per access? Or better still who will own the validated process for upkeep of multiple data sources to sell as a common process to the ADS owner. Presently BAAN, SAP, Peoplesoft, et al hold these processes tightly will the implementation of the universal translator allow for the movement of sets of common requirements from one integration broker(IB) to another when the mood hits? Or when the contract for the other IB is easier on the purse strings? The days when the ERP and even the IB are merely a set of common objects (commodities) is a worthy goal. Is this where we're headed?
vr
Walter S. Dyer III
- REST ist fine, but...
2002-02-25 23:50:56 Willy Müller [Reply]
Being able to access objects by an URI is fine
and desireable in many circumstances,
and REST might work in situations where I want
to save, read or delete data. You can use the HTTP operations to mimik database operations. But are the semantics rich enough to handle all we
want to do?
What if I want to use a web service for rotating a SVG object by an angle of 30 degrees?
What if the POST operation was part of
a distributed transaction that has to be rolled
back?
How do I POST an email?
After all, even the oldfashioned forms of the times of paper and pencil are nothing but a kind of RPC. A filled in oder form sent to a compony is ment to initialize a process that will eventually return me the products I ordered.
(Otherwise I'm not happy.)
Only the fact, that I send a message by mail, by email, by HTTP or some other transport mechanism does not make it more declareative, neither does the fact that the operation is hidden in an URI or a basic operation of HTTP.
A SOAP message could be seen as a declaration of the intent of the user and a kind of contract with
the service provider what he will get.
As user I like clear contracts. It makes life easier.
Are REST and SOAP really either-ors?
You can easily expose objects using URIs
that have been stored using SOAP.
You can use HTTP-POSTs to send SOAP
messages...
Willy Müller
- REST ist fine, but...
2002-05-19 13:14:04 Ron Wolf [Reply]
I'll admit that this is the 1st time that I've heard of REST as such, but the data-centric vs. API centric 'debate' has been going on for a long long time. Fact is, you need both. REST by itself does not make a system. Sure it's a good idea to have self-naming data and simple standardized access methods. This is the core of triumph of relational database (SQL).
Extending the data model to the network with XML makes a lot of sense. But to think of this as a system solution is naive. First off, just as databases change (adding columns, the meaning of existing columns evolves, ...) XML definitions (DTDs and semantics) will also be evolving living things. The tower of Babel may be better documented, but it keeps growing. In this regard REST has nothing over SOAP.
Secondly, and more fundamentally, at some point action needs to be taken. Action requires agreed upon sematics. And action is frequently more than insert this file, access that one. The database world partly addressed this via triggers. But the real solution has proven to be application servers with very complex semantics; real life is complex, sorry.
Pretty crucial that both the data and the action be clearly defined and agreed on. So, again, if systems are to work together, what is it that REST is really helping?
- REST ist fine, but...
- REST model of UDDI
2002-02-10 21:53:08 scott wood [Reply]
The REST model of UDDI described in this paper is
very similar to what the eCo framework defined a few years back:
http://eco.commerce.net/
If that's a "second generation" web service, I guess they were ahead of their time :-)
- "Hiding" URIs
2002-02-10 09:12:15 Marcus Groeber [Reply]
There is only sentence I would like to pick a nit with in this otherwise very insightful article: <<< It is easy to hide objects by merely never publishing their URIs. >>>
Many people had to learn the hard way that this is *not* a good way for hiding objects, after their "secret" internal web page suddenly appeared in a Referer header on some other site they link to, then found its way into a publicly available logfile and eventually ended up being crawled by every search engine possible...
This does not not invalidate the basic idea that all the security infrastructure developed for HTTP can be easily adopted for web services - but the problem doesn't simply go away all by itself...
- solve some, but not all problems
2002-02-08 06:40:09 Ben Hui [Reply]
this article did layout the problem correctly (SOAP being a RPC based technology). the URI-centric approach is the right direction, but I feel that the author get a little off topic on the second half of the article. the real problem is "we can reference a piece of data in a very decouple, yet flexible way. but now what? how do we operate? how do we use it?" the basic theory is "when we find, we want to decouple it, but when we use, we want to integrate it" it is the integration that make SOAP (and other RPC tech) so weak as a web technology because both side must agree on something to use the data. this agreement range from message format, message meaning, API, technology, to work flow.
bottom line: we also need to ground-breaking architecture for web services integration
ben
- Good to see recognition of REST
2002-02-08 06:28:45 Ian Fairman [Reply]
Three years ago, after reading about XML, XSLT,
XLink etc. I had similar sorts of ideas. Since
then I've been working with J2EE and EJB and it's
good to contrast to two. Fundamentally REST is
a declarative model and distributed objects are
procedural. REST is relatively simple, distributed
object require complex application servers (if
you want to do them right).
In my work I can't imagine a customer asking for
a REST solution, simply because everyone likes
to think their problems are so complex that they
need the heavy engineering a distributed object
solution provides. Coming from the other direction
I don't think many software architects would
suggest a REST solution because it's declarative
and doesn't fit in with the way they like to
think.
Don't get me wrong: I think a REST solution will
be better in most cases. Even when object
technology is needed it might be best limited
to individual nodes in the system. I'd bet that
many REST solutions in corporate settings are
the result of skunk projects where people can
get things done without asking for approval.
SOAP/WSDL/UDDI are a step in the right direction
with regards to commodotizing object technology
and encouraging interoperability, but the whole
name "web services" is slightly dishonest when
really SOAP is CORBA by another name.
