Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!

Leonard Richardson

author
+ Follow
since Jun 08, 2007
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Leonard Richardson

I think it is. The web has an object model that we're generally not using.
14 years ago
My lame design for a Java-style pet shop service (done for another thread in this forum) has one solution.

http://www.crummy.com/writing/RESTful-Web-Services/PetStore/

An order is a resource created through POST but initially empty. Subsequent requests add items to the order through POST. To commit the order you change its state with PUT so that it's finalized. Depending on the design, you might be able to DELETE or un-finalize the order so long as your credit card hasn't been charged.
14 years ago
One thing you could do is make a lease extension an unrequested side
effect of GET, a side effect like incrementing a hit counter. Section
9.1.1 of RFC 2616 says:

"Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, so
therefore cannot be held accountable for them."

This would mean that every GET request would extend the lease by some
amount of time. A resource would only die out if clients stopped
GETting it.

Alternatively, the expiry date is a bit of state of the resource, so
you could allow the client to change that state with PUT or overloaded
POST to the resource URL. If you used PUT, you'd need to have the client
send a proposed expiry date rather than a relative amount of
time, to keep PUT idempotent. Of course you could reject any
unreasonable dates.

Those are my two thoughts.
14 years ago
Ah, I didn't know you were responsible for Mojasef. I thought you were
just a user.

IMO the two most helpful features of a REST framework are attaching
objects to URLs and exposing the uniform interface methods as
native-language methods. Restlet does both (and a whole lot more).
I don't disagree that there's room in the ecosystem for a simpler framework.
14 years ago
The question you've asked goes to the heart of the difference between
RESTful web services and today's SOAP services, so this might not be
terribly intelligible. I will try my best.

A typical SOAP/WSDL service deploys a single "service" object (the
SOAP endpoint) and a WSDL document. The WSDL document points to the
URL of the service object, and describes the format of the documents
to be submitted to that URL.

A RESTful web service works more like a web site: it deploys a large
(probably infinite) number of objects, each with its own URL. The
client can get a description of an object by sending a GET request to
its URL. The description will contain information about the object,
but it will also contain links to related objects, and forms that
explain how to modify the object. The information that would go into a
WSDL file (the URL of the service, and what document formats the
client should use) is distributed among the many objects. Each object
describes itself.

The client starts at some known "home page" object, and follows the
cues to other objects. There are a number of technologies that a
service can use to convey these cues: HTML, WADL, "anyURI" nodes in an
XML document, etc. WSDL 2.0 technically falls into this category, but
it's almost never used for this purpose.

This leaves open the question of how the client knows the "home page"
URL, and how the client knows that the object at the other end of that
URL will help the client reach its goal. The closest RESTful
equivalents to UDDI are search engines like Google. These work well
for the WWW, connecting human beings to URLs that help them reach
their goals. But search engines don't really pick up web services. For
a variety of reasons this problem has not been solved. I expect that
when it is solved, the result will look a lot like a search engine, or
be part of a search engine.

To answer your specific questions:

I don't know if you can publish the URL to a RESTful service to UDDI
(Sam might know). Assuming you can, it's not going to look like other
services in the directory.

You can write a WSDL 2.0 file for at least some RESTful services, but
it's usually more trouble than it's worth. A framework that makes it
possible to generate WSDL for a RESTful service is conceivable, but I
don't think there are any.

Once the user of the web service knows the main URL for the service,
they can GET that URL and see links to other URLs. They will also see
forms that tell them what verbs to use.

What I've described is an idealistic scenario. In most real
services today, some of the links and forms are missing. You have to
read the equivalent information from a natural language document, and
program the information into your client.

I hope this helps. The book covers these topics in detail, especially
in chapter 10.
14 years ago
Vladimir, you can use HTTP pipelining (a feature of HTTP 1.1) to send batch GET and HEAD requests. You can also use Keep-Alive (another feature of HTTP 1.1) to make multiple HTTP requests without closing the TCP socket. Those optimizations should significantly cut down on your overhead. This is not covered in RWS, but HTTP: The Definitive Guide talks about it in chapter 4.
14 years ago
John, RESTful web services use GET requests only for read-only
operations on objects. For write operations they use POST, PUT, or
DELETE requests on the same objects. You can think of a RESTful system
as exposing a large number of objects, each of which can only respond
to four methods.

The Servlet API should be usable to build RESTful systems, but it's
not designed for RESTful systems. It's designed for traditional web
applications. I remember when I was writing servlets we had a separate
servlet class for each action. In a RESTful design I'd write a
separate class for each kind of object in the system.
14 years ago
Sonny, learning about SOAP does nothing to help you learn about RESTful principles. Theoretically there could be overlap, but there actually isn't, at least right now.

To answer your other question, you can use the principles of REST to design a website that people use. It's not just for web services.
14 years ago
Frank, I've been recommending Restlet because it's the only Java
framework I know of that's designed around REST. Its complexity stems
partly from the fact that it implements the whole REST dissertation,
not just its application to web services. There's certainly a market
for a simpler framework geared towards services.

Mojasef's architecture is a lot simpler, but the examples on the web
don't convince me that it's designed for read-write RESTful
services. Notably, the examples show a class variable (_n_, the visit
counter) changing in response to a GET request.

Now, something like a visit counter is fine as a side effect for GET,
because nobody makes a GET request just to bump up the visit
counter. But that example encourages the programmer to expose write
operations through GET, the way the Flickr and del.icio.us web
services do. The release notes also mention sessions, which violate
the principle of statelessness.

Looking at the example code I see a generic POST handler, which is the
kind of thing I'd expect to see if Mojasef made the programmer define
resources. But I'm not convinced that Mojasef is for RESTful
applications as opposed to REST-RPC hybrids like the Flickr API. I
could be wrong, and even if it's designed for hybrids you should be
able to use it RESTfully.
14 years ago
Jackie,

It stands for "Representational State Transfer" and it comes from Roy Fielding's 2000 Ph.D dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm). REST is a very general term, but it's usually used to describe a style of web services, or the architecture of the Web itself.

The acronym has to do with how client and server manage the state of server-side objects: by sending "representations" of the objects back and forth.
14 years ago
Dinesh, yes, that's more or less right. There are some other auxilliary verbs like HEAD, and PUT can also be used to create new resources.
14 years ago
John, I don't know for sure the answer to your question, but you will
probably have to wait for the JAX-RS standard (JSR 311).

Peer, "resource" is a deliberately vague term, about as vague as
"object". _Architecture of the World Wide Web_ (which I highly
recommend) says, "A resource should be assigned a URI if a third party
might reasonably want to link to it, make or refute assertions about
it, retrieve or cache a representation of it, include all or part of
it by reference into another representation, annotate it, or perform
other operations on it."

The uniform interface constraint only works because "resource" is so
vague. Many times when doing design I've run into a uniform interface
violation, and my eventual solution has been to expose some more
abstract thing, like a relationship, as its own resource. Much of what
I do in resource design is subconscious (the rest is described in
chapters 5 and 6), but I'm pretty sure that most of the normal rules
of object-oriented design apply. It's just that you have to apply them
under a very tight constraint.

It's _really_ hard to not end up with resources when you're making a
read-only dataset available through GET. Even if you deliberately try
for the RPC style, all you've done is create ugly URIs. From the
client's perspective it doesn't matter what the service designer
thinks: there's a fundamental congruence between the verb a RESTful
client sees (GET) and the verb the designer sees. Every GET request
runs some algorithm, whether the algorithm is addition or streaming
data from a file. But so long as the algorithm has no substantial side
effects, GET is appropriate and the URI can be seen as designating an
object.

The real test comes when the client needs to modify the dataset. Now
it does matter what the service designer thinks. If the designer truly
thinks of their resources as nouns, they'll decide it's time to break
out some of the other HTTP verbs and apply them to those nouns. But if
they're just following a "turn all the methods into nouns"
antipattern, they'll decide it's time to turn more methods into
nouns. This is how you get the Flickr URIs like
?methods=flickr.photos.delete exposed through GET. Now it's obvious
from an object-oriented standpoint (not just a URI ugliness
standpoint) that the Flickr designers didn't think of photos as
objects.

Anyway, I hope this helps.
14 years ago
Dinesh,

Messaging styles and message exchange patterns are concepts from SOAP,
and they're not used in RESTful analysis. Sam will know better than I,
but I'm pretty sure that describing HTTP in terms of the SOAP concepts
gives you document-literal for the messaging style and
request-response for the MEP.

Of course, you can implement other styles and MEPs on top of HTTP
(that's what SOAP does), but in RESTful design your thinking is
oriented around different concepts: resources, representations, etc.

Does this help?
14 years ago
M Easter,

To elaborate on what Sam said: in chapter 8 we give a RESTful system
for non-distributed transactions. I haven't done the work (I suspect
nobody has) but if you have a number of different systems that support
transactions, you should be able to add some infrastructure on top and
orchestrate them with a RESTful atomic transaction.

We didn't cover atomic transactions in detail because Sam prefers the
loosely coupled transactions of WS-BusinessActivity. In chapter 10,
probably in the ToC section you found interesting ("Transactions"), we
show how to implement the WS-BusinessActivity ideas with asynchronous
operations (which, in turn, are covered in chapter 8).
14 years ago
Hi Katie,

We recommend using four verbs, but you don't have to. You can use GET
for safe operations, and POST for everything else. The catch is that
the client should POST to the same URI it GETs. That forces you to
think of your URIs as designating objects instead of operations. (To
quote page 221, "REST says you should use a uniform interface, but it
doesn't say which one.")

So, lack of four-verb support is not a catastrophe, but the four do
help people step back from how web applications are traditionally
designed, and think of URIs as designating objects. The flip side of
that is you're not going to start using PUT and DELETE unless you're
willing to change how you think.

I'm amazed at the speed with which Rails went from having side effects
for GET to being totally based on RESTful resources. But heavily-used
libraries change very slowly, and often it's easier to write a new
library. This happened with Python HTTP clients: we have urllib,
urllib2, and now Joe Gregorio's httplib2. I think it will also happen
with web service frameworks.

This was kind of rambling but I hope it answered your question. By the
way, you kind of switched PUT and POST. PUT is for updating resources,
and for creating brand new resources. POST is for spawning a new
resource from an existing one.

Leonard
14 years ago