Account services

URL style

Fifteen years of software development has taught us that no technology lasts forever. It is inevitable that software will be rewritten, and for a second generation website, emulating the telltale signs of the previous technology can be a real chore. Telltale signs are the suffixes such as .php for PHP, .jsp for Java Server Pages etc. We therefore have chosen to adopt a URL style that avoids suffixes and question marks (?) for one-subject pages.

Preferred URL style:

  http://rod.eionet.europa.eu/obligations/887
  http://www.eea.europa.eu/articles/water-for-agriculture
  

Even the “innocent” .html used for static pages must be avoided. Because what is static today will be dynamic tomorrow. If the page has .html as its suffix then to achieve persistence the webserver must often be configured to return dynamic pages for all .html pages. Then you get into conflicts over which technology has the privilege to serve .html pages. If you employ multiviews you can let your static page with the name “tasks.html” be available on the webserver as http://www.eionet.europa.eu/tasks. Then if you need to make it be generated dynamically, you just set it up as tasks.php and still make it available as http://www.eionet.europa.eu/tasks.

Another example of bad style is when the same source file is used to contain the information that really belongs in two or more files.

  http://...eionet.europa.eu/help.jsp?page=2
  

This can be fixed with a simple RewriteRule in Apache, making the user see http://...eionet.europa.eu/help/2, but the application see the above. It is still better if the application did this natively.

  http://...eionet.europa.eu/show.jsv?id=171&aid=211&mode=A
  

The next example is more complex. It would be natural to split the show.jsv into two or more files. One per value for the mode parameter, and then employ the rewrite rule from the first example.

Design heuristics for webpage names

  1. Avoid "." and "_"
  2. Use common natural language words
  3. Use all lowercase characters
  4. Avoid using unnecessary parameters (i.e. arguments of the type ?species_id=19882&lang=en)
  5. Avoid using identifier names that might change in the future

Ok, I must have clean URLs — now what?

Now you can consider how to structure your website to match the URL style. A static website is just a hierarchy of folders and files, and there is not much to design. It gets much more interesting when certain pages are operations on a database.

Eionet operates with a object oriented paradigm. It is something we have inherited from Zope. The principle is: Folder/Folder…/Object/method.

Viewing an object
/obligations/374/view
tableobjectmethod

To view an object, you would normally need “r” permission for /obligations/374.

Inserting an object
/obligations/insert?id=374
table (object)methodsubject

This example is somewhat misleading. You should implement an insert-operation as a HTTP POST, as it changes state, but the POST operation doesn't put the arguments in the URL, and therefore wouldn't be an understandable example. To insert an object, you would normally need “i” permission for /obligations.

What would /obligations/374 do? It would in most circumstances be a default view-operation, just like Apache shows index.html for a folder. Exactly what parts of the object is viewed is up to the developer to decide.

References