RE: Proposed text on reliability in the web services architecture

If it looks like an SQL UPDATE and quacks like an SQL UPDATE then it must be
...

Ok. So there's 1000 lines of code for my operation and it takes two days to
implement it. Care to discuss it?

I am trying to discuss the value of REST and in order to simplify the
discussion I am picking a very trivial application of REST that is so easy
to do we don't have to discuss the technical details. We can assume it's a
very trivial mapping.

I am not saying REST is only good for SQL UPDATE. I am simply trying to make
a very concise discussion by trying to simplify the definition of a
hypothetical service.

If this hypotherical service is not good let's just drop it.

arkin


> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: Friday, January 10, 2003 5:54 PM
> To: Assaf Arkin; www-ws-arch@w3.org
> Cc: Champion, Mike; bhaugen
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
>
> Assaf Arkin wrote:
>
> > Let's assume for the second that all SQL upates are idempotent. (Not
> > necessarily, but it simplifies the discussion) And SQL selects don't
> > have any side effects (not that I know of). So mapping SQL statements
> > to HTTP GET/PUT would make my database RESTful (correct?).
>
> I don't think it is useful to think of it as mapping SQL statements to
> HTTP GET/PUT. You have abstractions you want to expose to your
> customers. You develop a set of resources that are a logical, secure and
> abstract view on those resources. Some of the data underneath those
> resources may be expressed as relational tables. Other bits of it may
> come from anywhere else.
>
> > Persumably, if I expose my database as a Web service I could build a
> > RESTful service. And it will scale as well as the database does, which
> > is not a bad proposition (afterall most applications simply add
> > overhead to the database).
>
> A REST web service will scale as well as it is architected to. The
> chances of it scaling in exactly the same fashion as some particular
> data source seems vanishingly small.
>
> Let's not get confused about the relationship between HTTP methods and
> relational data. The point is NOT that there is a straightforward
> mapping which allows the removal of an intermediate layer.
>
> > putting a middle layer between the client and the database.
>
> Mike Champion is correct that it takes effort to insert a REST layer
> precisely because it _is_ a layer. And because conforming to standards
> (whether architectural standards or syntactic ones) always takes more
> effort than just doing what you were doing before the standard came along.
>
> >  Instead of
> > performing database operations, the client performs application
> > operations which then become sequences of database operations. One you
> > sequence a select and an update, or two updates, with some logic,
> > you're no longer 100% idempotent  How much, I never bothered to
> > measure. 20%? 40%? 60%
>
> I have no idea what this means.
>
> > You don't have to do it. You can build a system out of a set of small
> > idempotent operations.
>
> No you cannot. In general, you cannot build most useful systems out of
> only idempotent operations. That's why HTTP does not provide only
> idempotent operations.
>
>   Paul Prescod
>

Received on Tuesday, 14 January 2003 21:32:43 UTC