Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] REST by example?

Expand Messages
  • Holden Glova
    ... Hash: SHA1 Hello Lucas, ... Erik: along side the address book example, what about a bookmark manager? It could manage bookmarks in one central place. ...
    Message 1 of 11 , Apr 17, 2002
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Hello Lucas,

      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
      following?

      http://somehost.com/employee/create?id=12345
      http://somehost.com/employee/update?id=12345

      Then on the server side there would be a create, update method on the
      employee that takes an id parameter?

      - --
      Signed,
      Holden Glova
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.0.6 (GNU/Linux)
      Comment: For info see http://www.gnupg.org

      iD8DBQE8vdlD+mF116Lw2cQRAsc4AJ4nsg8pRCE7YdYpTK8DQs8ve1x9jQCdEJFI
      LrLuNyMH2c/Z+MhKwJlI/m0=
      =/bI4
      -----END PGP SIGNATURE-----
    • S. Mike Dierken
      ... From: Holden Glova ... commonly ... The URLs should be objects that support the generic methods of get, put, post, and delete rather
      Message 2 of 11 , Apr 18, 2002
      • 0 Attachment
        ----- Original Message -----
        From: "Holden Glova" <dsafari@...>

        >
        > 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
        > following?
        >
        > http://somehost.com/employee/create?id=12345
        > http://somehost.com/employee/update?id=12345
        >
        > 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
        functionality.
        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
        (idempotency).
        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)
        PUT http://somehost.com/employee/12345/

        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 -
        an 'upsert'.
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.