Strokedb Zoid

(This document is WIP and I am open for suggestions. This document is definitely incomplete atm)

Zoid routing is supposed to be hard-coded (this might change eventually, but lets forget about it now). The reasons are simplicity and speed.

Each request to Zoid app is matched against following criteria:

• request method (PUT and DELETE are transparently tunneled through POST and _method parameter)
• full request path

Routing Patterns

Here is the list of Zoid routes I foresee now:

• GET /plural_meta_name

Example: GET /users

This request is routed to User.index (class method). Since Zoid extends Meta with its own set of methods, if User has no index method then Meta#index shipped with Zoid will handle it.

• POST /plural_meta_name

Example: POST /users

This request is routed to User.create!()

• PUT /plural_meta_name

Example: PUT /users

This request is routed to User.document.update_slots! probably. I am not sure it is a good idea to allow editing meta document, but we'll see

• GET /plural_meta_name/method_name

Example: GET /users/new

This request is routed to User.new (class method). Since Zoid extends Meta with its own set of methods, if User has no index method then Meta#new shipped with Zoid will handle it.

• GET /plural_meta_name/uuid(.version)

Example: GET /users/02c231fa-eef3-416a-a51d-e543abcd6d4e or GET /users/02c231fa-eef3-416a-a51d-e543abcd6d4e.00000000-0000-0000-0000-000000000000

This request is routed to User.find(uuid,version).show method. Since Zoid extends Document with its own set of methods, if User has no show method then Document#show shipped with Zoid will handle it and render it with default layout.

• GET /plural_meta_name/uuid(.version)/edit

Example: GET /users/02c231fa-eef3-416a-a51d-e543abcd6d4e/edit or GET /users/02c231fa-eef3-416a-a51d-e543abcd6d4e.00000000-0000-0000-0000-000000000000/edit

This request is routed to User.find(uuid,version).edit method. Since Zoid extends Document with its own set of methods, if User has no edit method then Document#show shipped with Zoid will handle it and render it with default layout.

• PUT /plural_meta_name/uuid(.version)

Example: PUT /users/02c231fa-eef3-416a-a51d-e543abcd6d4e

This request is routed to User.find(uuid,version).update_attributes! method. If version is included into request, then versioned document is updated

• POST /plural_meta_name/uuid(.version)

Example: POST /users/02c231fa-eef3-416a-a51d-e543abcd6d4e

This request is routed to User.find(uuid,version).set_attributes! method. If version is included into request, then versioned document is updated

(Note: there is no #set_attributes! method yet)

This method differs from PUT one in one simple aspect: while in PUT you should specify only those slots you want to update, in POST you're creating new version from scratch.

Note: I am not yet sure we need this method of document update

• DELETE /plural_meta_name/uuid

Example: DELETE /users/02c231fa-eef3-416a-a51d-e543abcd6d4e

This request is routed to User.find(uuid,version).delete! method

Specifying arguments

Each request, like GET /plural_meta_name/uuid(.version)/edit, GET /plural_meta_name/method_name, etc. can accept extra arguments. Rules are simple enough: all values separated by slash ('/') until question mark ('?') are considered to be usual method arguments; all request parameters are assumed to be a Hash and passed to method as a last argument.

So, for example, GET /users/02c231fa-eef3-416a-a51d-e543abcd6d4e/items/0?theme=new will be translated to User#items(0, 'theme' => 'new')

Some notes:

• Security issues are to be addressed in another document
• Each request path could be appended with "file extension" to specify format explicitely without tuning Accept: header (aspects of multi-format rendering will be addressed in another document)