Re: [rest-discuss] REST by example?
- -----BEGIN PGP SIGNED MESSAGE-----
On Thu, 18 Apr 2002 02:19, Lucas Gonze wrote:
> Erik wrote:
> > However, I am not particularly interested in converting any existing
> > technology into REST based ones.
> > I am interested in simple (small) examples that demonstrate the REST
> > approach with a 'readable' language like Ruby or Python, using only HTTP
> > and URIS (and in more complex examples XML).
Erik: along side the address book example, what about a bookmark manager? It
could manage bookmarks in one central place.
> During the morning commute I came to more or less the same conclusion.
> In general there needs to be a listing of design issues with an example
> for each. The stuff on the REST Wiki right now is too abstract.
As a very new comer to REST I am still having a hard time thinking about how
it works with a real application from an implementation point of view.
> Design issue: resources not methods
> Example: SQL insert
> One way to do a SQL insert over the web is to wrap the SQL in HTTP syntax.
> For example,
> GET /doInsert?cols=id,val&vals=25,fooVal&table=myTable
> A REST way of doing this would
> * be strict about not using GET to change server state
> * have the back end target be a resource rather than a procedure
> New way:
> POST /tables/myTable?id=25&val=fooVal
> - Lucas
Surely this would be very bad as anyone could insert whatever data they
wanted into your database. Database access/manipulation IMHO is something
that should definately live behind a facade. I would generally prefer to not
even expose dataaccess routines to the outside world but wrap those up in
something that communicates what the data is doing. Without doing a REST
example, because I don't understand it yet.
I would do something like employee.create, or update etc...This is commonly
termed as the CRUD approach. In REST would this be something like the
Then on the server side there would be a create, update method on the
employee that takes an id parameter?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
----- Original Message -----
From: "Holden Glova" <dsafari@...>
> I would do something like employee.create, or update etc...This is
> termed as the CRUD approach. In REST would this be something like the
> Then on the server side there would be a create, update method on the
> employee that takes an id parameter?
The URLs should be objects that support the generic methods of get, put,
post, and delete rather than urls with the methods themselves (no matter how
tempting it may be, and I'm just as guilty of ignoring that as anyone.).
The 'post' operations means 'modify' and it could be implemented to
add/subtract/extend/whatever. It can also optionally return the ID of a
newly created resource.
In HTTP there are similar but different operations for CRUD type of
Two are easy, GET=Read and DELETE=Delete. With HTTP you have two choices to
create new data, POST and PUT, depending on who knows the desired ID, as
well as how you want to deal with safely repeatable operations
You use PUT when the client knows the desired ID and POST when the server
will generate the ID. So in your example, you only need to use one HTTP
method (since the client is providing the ID of the new employee)
In a database if you INSERT with a duplicate key, it fails. If you UPDATE a
record that doesn't exist it fails.
With PUT the record is created if it doesn't exist or updated if it does -
With POST a record is created and the key is returned - and wacky things
happen if you call it twice...
CRUD (create, read, update, delete) is a framing of REST over relational
databases (or vice-versa...)
REST has the attitude of 'lots of nouns, few verbs'.
Databases follow this very succesfully. Although we always talk about
GET/PUT/POST/DELETE, those are just one example as applied by the HTTP. It
is useful to compare the two (and others.. I should start a page on the
Wiki...) and consider issues like:
- are the operations safely repeatable
- who controls the ID (primary key, etc)
- can you create an empty resource and fill it in later