Michael Terrington wrote:
Absolutely, either is valid. I prefer to keep related things at the same level of hierarchy (i.e. the same folder).
Say there's thousands of these, would you still have them in one folder?
Hundreds of thousands? At which point do you change your thinking?
We're talking about information organization hierarchy, not the fact
that a dynamic web application can happily spit out an infinite amount
of representations in the same "folder".
Again, it's about the metaphor. A slash metaphor vs. a comma metaphor.
I can't say I see that as any kind of improvement unless .../jobs/en/
and .../jobs/en/de/ are also resources you might want to address.
Several improvements:
a) As you suggest, a GET to ../jobs/en/ might be an interesting URL.
Ie. "show me all translations from english to any language".
b) Or similarly, ../jobs/en/de/ "show me all translations from english
to German."
b.1) ../jobs/en/de/?date-range=2007-01-01,2007-2007-07-18 "show me all
translations from English to German within a specified date range"
While a) & b) may not be currently functional in this guy's application,
having the URLs setup up in this manner is helping to future proof it.
b.1) is a good example where a comma in the date range make sense to me.
c) The possibility exists to separate which web servers serve the
resources a bit easier. I guess you could have a reverse proxy which
forwarded to another server based on the comma. But again, it's just
common to do these types of routings based on a slash character.
That is to say for c), you can "scale" better with the ../jobs/en/de/
hierarchy for GET requests.
The character itself is arbitrary. Since the good folks at Bell Labs
decided to use a slash, I guess that's the best metaphor. If we could
turn back the clock, maybe instead we'd be using | or - or #.
Adam
