"Victor Engmark" <address@hidden> wrote:
> Unless this problem can be prevented completely, I suggest we scrap the
> idea. It's nice to have short URLs, but removing the variable names results
> in:
>
> - Less flexibility, since you can't change the sequence or number of
> parameters without breaking URLs.
That's nonsense. I explained that some parameters should remain as
queries.
But which ones? I'd bet that some of the initially required parameters will be demoted to optional, and then you've got to hack around the limitations of this method. Also, why mix methods? IMO, we should only use slashes in the URL when the next piece of information is self-explanatory as a subset of the previous one, and it's the
only natural way to browse within the set. E.g., "/vacancies/{persons|companies|organizations}" is a valid subdivision, but so is "/vacancies/{Australia|Belarus|Belgium|...}". In cases like this, using a parameter name makes sure we'll never have to deal with overlap, and the purpose of the URL is clearer.
> Since people will be using old URLs,
> every time we change the structure we'd have to program around those, to
> make sure people don't get weird results when they go to the page.
You should do that anyway:
http://www.w3.org/Provider/Style/URI
Of course. What I meant is that with parameter names you'll have a much easier job, since there will be no ambiguity as to which parameter should get value X.
> This
> could be mitigated by including some version number in the URL, but do we
> really want to hang on to such legacy code till the end of time?
> - More work, as obvious from the above.
I don't see why a version number in the URL is necessary.
If you want to be able to handle old URLs when omitting (some) parameter names, you can either have extra code to guess which revision of the parameter scheme the URL uses (which will grow by what, N log N, with number of revisions?), or use a version number. In any case, you'll need extra code to handle each revision.
> - Less usability, since users will have a harder time to figure out
> what to edit in the URL to get other results. Editing something like
> "?q=developer+sql&min_salary=1000&cur=USD&per=day&loc=Hawaii" is IMO a lot
> simpler than "/developer+sql/1000/USD/day/Hawaii/", especially when you have
> lots of parameters, and especially when some of them are null.
With that q in there, that looks like a search, which is something
which should remain as a query, because it's a query. Only things
which are pages rather than queries should become pages.
OK, I should have removed the "q" parameter, but the point is still valid. "/vacancies?type=developer&field=SQL&min_salary=1000&max_salary=2000&cur=USD&per=day" is IMO less ambiguous than "/vacancies/developer/SQL/1000/2000/USD/day".
> > Not all optional parameters should be part of the URL - you can put
> > some in, but they have to be on the end of the URL - so some might end
> > as query strings. It depends how much you want them to be indexed by
> > search engines and so on.
>
> Search engines are another reason to drop this - They show you the URL in
> the search results, and that should be readable even to outsiders.
I think /offers/general/36 is more readable to outsiders than
/offers.php?ADY*SA&D*(AHK!"Y£(*^DIAYTDA
I hope you're joking now, and not just trolling. A realistic URL would be something like "/vacancies?type=developer&org=CERN&field=webdev&min_salary=2000", which is (again, IMO) much more readable to an outsider than "/vacancies/developer/CERN/webdev/2000/". An outsider would have to click the link to see that "CERN" is an organization, not a company, and that "2000" is the minimum salary.
> Also, this is a lot of work for IMO very little gain. [...]
Have you ever switched a site from query URIs to page URIs to test
the gain?
No, because I realize the gain is only for those who are very familiar with the site. You can't expect that even if you're the undisputed world leader, and
even
they don't
use
this method.
Usability studies have found that users don't care about your site, and they are
not willing to learn anything that violates design conventions (see
#8).
> As far as I can see, this is only OK in special cases. What if you want to
> edit all of the vacancies you've posted?
/offers/my/all/edit perhaps?
> Or only those for Python developers?
/offers/my/python/edit perhaps?
> Or only the second, third, and fifth offer, selected from a
> list?
Start at /offers/my/all and click edit links?
The point is, this could easily be extended to any filtering criterion by using normal URLs. No "//////CERN//", just "?org=CERN".
I don't see where the problem is with using page URIs when appropriate.
Extra complexity which only benefits those very familiar with our site, and breaks URL readability, flexibility, and de facto standards. Those are
huge problems which I'm sure we'll have with this approach.
--