
Solving the TinyUrl centralization problem - nreece
http://www.scripting.com/stories/2009/03/07/solvingTheTinyurlCentraliz.html
======
dcurtis
There are two things to take into consideration here. I agree with the premise
of what the author is saying, that URLs should be as short as possible, but I
also think URLs should be informative as well. The amazon.com/wii url is great
because it contains information about where you're going. If that was
amazon.com/sD5E, I would have no idea where it's going to send me. This is the
biggest problem with Tinyurl, I think.

URLs should be as simple and short as possible _but not too simple and short_.
It should still tell me where I'm going, just extremely succinctly.

I see developers make this mistake all the time. They make their URLs look
like this: _<http://example.com/users/dcurtis/profile> _. That has at least 14
useless characters in it. It could be changed to _<http://example.com/dcurtis>
_ with no loss at all, because /users and /profile both are useless structural
information.

~~~
gry
As always, it depends. Arguably, <http://example.com/users/dcurtis/profile> is
short, but not too short. If a website/service is centered around people, it
makes _more_ sense. Else, the longer URLs seem to make more sense.
<http://www.amazon.com/wii> is only as useful as someone knowing what the Wii
is.

I wouldn't consider the users and profile namespaces a mistake. People get
cute and it can create a large constraint how your architecture works. Also,
URLs structures as such are often a result of some framework behind it.
<http://example.com/model/controller/view>. It expedites development and
managing code something fierce. Perhaps there is opportunity for a shortening
widget within the MVC pattern. I need to think about it -- or let other
smarter people than me think about it. :)

<http://www.amazon.com/shamwow> is invalid, along with the other permutations
I tried. Amazon doesn't have core shortening service, it seems.

I think the issue is more around URLs which can be parsed by a human vs the
proverbial querystring. A TinyURL solves technical problems and looks nicer
which is 2/3 of the way there. The remainder makes sense to a person.

~~~
dcurtis
You can't use the excuse that "the software urges me to do it this way, so
I'll make the user's experience suffer." As a developer of user-centric
software, it is totally your responsibility to do al the hard work for the
user. That includes the couple lines in your routes file to fix the
/model/controller/view default.

/users and /profile do not ever have extra information, except in extreme
cases where you have /users and /aliens and /pants that your app is
centralized around.

~~~
jaaron
/users and /profile could easily have extra information. a GET /users could
provide a list of all users. the /users/dcurtis might be the blog or home
page, while /users/dcurtis/profile is specifically the person's profile.

Having a hierarchical resource namespace makes plenty of sense in many
contexts. If nothing else, it's more likely to be long lived because it makes
URL redirection easier in the future if the system changes. When version 2 of
the site software comes out, someone can easily redirect all the /profile urls
to a legacy system or parse them into the new system. Whereas a flat namespace
is much harder to migrate and keep constant.

And besides, we shouldn't confuse the two issues of readable URLs and short
alias URLs. Both have very legitimate uses.

~~~
dcurtis
You're right that /dcurtis could have different information. But I am talking
about webapps that would return a 404 for _<http://example.com/users> _. The
vast majority of major apps do not use urls the way you described.

Unless you absolutely positively have to have another extra layer of url
hierarchy, and you can justify it extremely well, please don't. It's just a
burden on the user when they go to share/copy/read it.

------
jrockway
Long URLs don't bother me. The actual URL is an implementation detail for the
computer. As a user, all I should see is an underlined description of the
link. When I click it, the computer takes me where I need to go. It doesn't
care how long the URL is, because it just doesn't matter that much.

I have successfully cut-n-pasted long URLs into IRC, Email, and IM, and it has
never not worked. It may be a bit ugly, but who really cares?

~~~
jgfoot
One time when URL shortening is useful is for paper. I write legal briefs that
sometimes have to cite to web pages, and for that URL shortening services are
very useful. You can't expect a human reader to type in 200+ character URLs.

------
thorax
Services are already doing some of this. TipJoy can do their own URL shortner,
FriendFeed has ff.im, Posterous has post.ly, etc. This is getting pretty
common.

If you're not going to make your own, and are obsessed with shortness, though,
we just launched our own shrinker:

<http://tinyarro.ws>

<http://➡.ws/퐐>

------
jgfoot
TinyUrl is run by one dude in Minnesota, an avid unicyclist named <a
href="[http://www.gilby.com/whois.html">Kevin](http://www.gilby.com/whois.html)
Gilbertson</a>. It gets 1.75 billion hits per month. How long is this going to
last?

~~~
unalone
Is there any reason that it won't last just because it's a one-man shop? He's
kept it going strong this far.

~~~
jgfoot
It's tied to the life, and devotion, of one person. He could get sick, he
could die without making arrangements, he could stop being able to pay his
server bills.

~~~
whughes
He could, but is there any reason to assume that he will? There's always out-
of-nowhere conditions that can kill off an operation. He appears to be having
no trouble thus far, so I don't see any reason to predict that he will
encounter trouble without a basis in reality.

------
TweedHeads
the solution has been at our fingertips since the web was born:

a href="longurl" : shorttext

