openSUSE:Build Service Future Routing

Jump to: navigation, search

Routes by name vs by id

Given the following example model (simplified MySQL): 

   CREATE TABLE `architectures` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `name` varchar(255) NOT NULL,
     PRIMARY KEY (`id`),
   );

It is assumed that there is a correspoding Ruby model and controller with the actions 'index', 'show' and 'update'.


Current state of OBS-2.x

Possible requests:

   GET /architecture                   <- listing of all
   GET /architecture/x86_64            <- show arch with name "x86_64" (secondary key)
   PUT /architecture/x86_64            <- update arch with name "x86_64 (secondary key)

Resulting routes.rb entries:

   map.connect 'architecture',       :controller => 'architecture', :action => 'index'
   map.connect 'architecture/:name', :controller => 'architecture', :action => 'show',   :conditions => {:method => :get}
   map.connect 'architecture/:name', :controller => 'architecture', :action => 'update', :conditions => {:method => :put}

Advantages:

  • Better human-readable URLs
  • No other 'name' lookup needed when 'name' is known.

Disadvantages:

  • Needs an index over 'name' column in 'architecture' table to be fast
  • Still no guarantee if given 'name' actually exists
  • Joining over primary key _always_ involves lookup of 'name' (in index, though)
  • If you want routes to be persistent (i.e. found in pasties, shortened urls or caches), you can never change the 'name' of an arch.
    • Less of an issue for architectures, but bad in general

Wanted state (In a galaxy far far away)

Possible requests:

   GET /architectures                  <- listing of all
   GET /architectures/1                <- show arch with id 1 (primary key)
   PUT /architectures/1                <- update arch with id 1 (primary key)

Resulting routes.rb entry:

   map.resources :architectures

Advantages:

  • Always lookup by primary key (id), FASTER!!!
  • Possibly no index over 'name' needed, means halved MEM reqs for indexes
  • Rails automatically generates routes and correctly maps HTTP methods (GET,PUT) to correct controller actions.
  • Joining over primary key _may_ involve lookup of 'name' (in index, hopefully)
  • A listing as first step reduces the change that user queries a non-existing arch 'name'
  • This is what everyone does (may be less of an argument)

Disadvantages:

  • Less readable URLs
  • To get arch of name 'x86_64', a lookup is needed. Still less of for UIs, users always select sth. from lists.
Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:Build_Service_Future_Routing&oldid=37784"