Brad Fitzpatrick (bradfitz) wrote in lj_dev,
Brad Fitzpatrick
bradfitz
lj_dev

URL thoughts; take 3

Thanks for the good comments in the last post.

Here are my latest preferences and justifications for the URL format change. But first off, my apologies if you don't like this mode of discussion, whereby I keep reading all comments in prior posts and then posting top-level again. I think it improves visibility and speeds things up, though.

Issues:

Two URLs for one resource is bad. Agreed. The fact that friends/ and friends both work is an accident. I'll be fixing that. I could also make an option to let users choose their canonical user: /users/, /~/, or users.livejournal.com and we'll do redirects and always use their preferred link type.

Dates in canonical item URLs are problematic. Yeah... the date could change. But we could redirect to the new date. But other arguments were more valid: clients would need the date to make URLs, it's long, it's redundant, etc. But the best reason is that I still want to support "dateless entries" in the future, Wiki-style or something. And for that, no date in the URL is good.

Disambiguating years from itemids. So if we're going with the short version of item URLs, there are multiple ways to disambiguate yyyy from nnnn (which could potentially be year-like). One proposal was zero-padding it to 5 digits. Kinda ugly. One was /entry/itemid. Longer, and has English. I'm still siding with .html, even though some people like evan don't like it. My counter-argument is: the alternatives are uglier, and this is still a shorter URL than including the dates. Hell, we could even redirect from account/itemid when itemid isn't ambiguous. But .html would be canonical, for spiderability.

Trailing slashes or not. If it's a container for other items, it's a directory in my mind, and directories end in slashes. Also, trailing slashes says "index me!" just a tad bit more. (but really, search engines don't use that metric much from what I've seen...) However, just as Apache redirects a directory request without a trailing slash to a URL with a trailing slash, we could do the same... so you can type account/yyyy and be redirected to account/yyyy/

So, my current thoughts for canonical resources:

account/yyyy/
account/yyyy/mm/
account/yyyy/mm/dd/
account/itemid.html

And the item view could include a form for posting at bottom, as decklin mentioned, or urls like replyto=nnn would work. All that is less important and could be worked out later.

I'm not going to go with a /reply scheme though... it'll be a question mark and CGI-style arguments with doing some action on the entry.

Please give me your thoughts on this latest proposal. If there seems to be general consensus, this will go live soon. If there are some good arguments, we'll delay things and later maybe vote or something.... not sure. But I think we can get everybody happy, as long as everybody understands the justifications.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 28 comments