This week's giveaway is in the Threads forum.
We're giving away four copies of Java Concurrency Live Lessons and have Doug Schmidt on-line!
See this thread for details.
Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Changing the way we think for ROA  RSS feed

 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In RESTful Web Services:About the book it was said:
Originally posted by Leonard Richardson:
But no matter what, you'll have to change the way you think about web services. REST is a style, not a technology.


Even in SOA there seems to be a real chasm between prevalent RPC-thinking and desirable "document-oriented" thinking. The gap between RPC/Services (verb) and Resource (noun) thinking seems to be even greater. Isn't this gap going to seriously impede the adoption of REST design principles and ROA?
 
Leonard Richardson
author
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peer,

I suspect they're the same gap, and that the confusing factor in both
cases is the verb-focused way most of us write computer programs. We
want distributed programming to work exactly the same way, with a wide
vocabulary of verbs taking center stage. I would argue this is
responsible for the RPC style of SOAP programming in the first place.

Insofar as there is a secret weapon, it's the Web. The Web is a noun
composed of other nouns: sites, pages, documents. We've internalized
rules about these billions of nouns: that each one has a name, that
they link to each other, and so on. We don't think of a large
vocabulary applying to them. Taking that as a starting point, it's not
too far to the idea of programming an infinity of nouns through a
standardized interface. But it's not a sure thing that it'll catch on.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank You for your response.

Interesting.
So far I've perceived the gap between tightly coupled RPC vs loosely coupled documents as one governed by granularity. If your granularity is too fine you need lots of "operations" to accomplish anything, ultimately leading to a "chatty" system. At a coarser granularity enough information is carried within the transferred data to imply to the server what needs to be done - there no longer is a requirement for the client to direct (micromanage) the server, reducing the required number of externally accessible operations.

In the sample Chapter 4: The Resource Oriented Architecture) you actually give "a row in a database" (p.81) as an example of a resource. Isn't that level of granularity typically a bit too fine? Wouldn't you usually aggregate your resources to a much coarser granularity?

Another example of a resource that really surprised me was "the result of running an algorithm". How is that different from deploying a service at a specific URL?
 
Sam Ruby
author
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the sample Chapter 4: The Resource Oriented Architecture) you actually give "a row in a database" (p.81) as an example of a resource. Isn't that level of granularity typically a bit too fine? Wouldn't you usually aggregate your resources to a much coarser granularity?


You often would. A search result may show 10 to 50 rows. A directory listing may show hundreds. Each result would be hypertexted linked to something that is of a finer granularity.

Another example of a resource that really surprised me was "the result of running an algorithm". How is that different from deploying a service at a specific URL?


Services and resources aren't non-overlapping sets. Is google.com a service or a resource?
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, as you mention google...

In Chapter 4: The Resource Oriented Architecture on p. 85

is handled as an address to a resource. Granted the word search is both a noun and a verb - though I think it has a "verb smell" to it, especially as the query parameter makes it look like a method invocation. So this seems to violate the spirit of "2. Create a URL to each resource. The resources should be nouns, not verbs." as listed in Roger L. Costello's Building Web Services the REST Way.

Other REST Best Practice articles like Implementing REST Web Services: Best Practices and Guidelines seem to suggest that the resource address should be completed by the end of the path component of the URI (otherwise how can you have "query parameters that are not understood" - some query parameters are part of the "address", while others aren�t?). Query parameters are usually only used to specify a particular representation or view of a resource.

If you include the query component of the URI as part of the resource's address wouldn't that imply that every possible query parameter is part of the resource address? Wouldn�t that further imply that even each available resource representation and view is in fact a different (independent?) resource?
 
Leonard Richardson
author
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peer,

Everything about URI construction goes in the realm of best practices and has no real effect on whether something is a resource or not. We give some pretty detailed URI construction advice in chapter 5, but it's just advice.

In chapter 1 we discuss "REST-RPC hybrid" services like the Flickr API, which were designed for the RPC style but have some RESTful qualities by accident. All that matters is whether GET to a URI follows the HTTP rules for GET, (similarly for POST etc.). To quote from p236 ("Permanent URIs vs. Readable URIs"), "REST says that resources should have names, not that the names should mean anything."

You can look at two URIs as pointing to different resources, as two names for the same resource, or as different representations of the same resource--it depends on what's most helpful for understanding the underlying abstraction. Usually the choice is obvious, but sometimes reasonable people can disagree. The note on page 280 gives an example where the APP spec describes two resources, but I think it makes more sense to think of two representations of one resource.
[ June 13, 2007: Message edited by: Leonard Richardson ]
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank You for your patient responses.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!