URI DEV: Difference between revisions

From AniDB
Jump to navigation Jump to search
(the first few ideas)
 
Line 51: Line 51:
:*http://anidb.net/anime/1
:*http://anidb.net/anime/1


and this:
:*http://anidb.net/perl-bin/animedb.pl?show=addanime&edit=1
:*http://anidb.net/perl-bin/animedb.pl?show=addanime&edit=1
becomes:
becomes:
:*http://anidb.net/anime/1/edit
:*http://anidb.net/anime/1/edit

Revision as of 16:44, 29 January 2008

General

The current URI system is a mess made up of different sets of parameters for the same purpose depending on who and when wrote somehting. the idea is to first to remove unneccessary stuff from it, second standarize parameter and third make ir richer in feature

Guidelines

URI's:

  • don't change
  • are human guessable
  • are logical (no need to mirror a filesystem)
  • help visualize the site structure
  • are short
  • use lowercase
  • don't use unexpected punctuation
  • lack query parameters
  • allow public linking
  • are stateless
  • dont expose technology

what not to do:

  • use plurar for parameter when you shouldn't (i.e. animes/5 instead of anime/5)
  • use "=1/=on". if the parameter is in the url it IS on. if not it's not which leads to
  • don't add unneccessary parameter


Vision

  • 1(!) standarized Parser through which the data passes first
  • unnessary scary things like /perl-bin/animedb.pl
  • structured URI
  • standarized parameter
  • let http://anidb.net/gonzo or http://anidb.net/chobits use the Full Text Search and return useful stuff instead of failing ([1]])
  • use dictionaries where possible and avoid unneccessary &
  • ...

shortterm simple Changes

  • get rid of "/perl-bin/animedb.pl"

yes we use perl. no we don't need to throw our "perl penis into the face of everoyne else" (as rar calls it)

  • ...

Design idea 1

parameter could be something like

  • /h&mylist&noalias&wishlist&orderby.name.desc

in full example this:

could look like this:

this:

like this:

and this:

becomes: