Definitely a good idea. I personally know that it's difficult to keep links around when they are implementation-dependent.
Look at my blog for example; with URIs like /comments/b31956d4-3dd1-11de-ba89-db8db9812c92/b5a70270-3dd1-11de-a405-db2750a175d7/b5a70270-3dd1-11de-a405-db2750a175d7.pod, it is going to be a nightmare to keep all links alive when I rewrite the software. In this case, I think I'm going to just kill them, since nobody links to individual comments. But I am not the NYT :)
That'll teach you not to use GUID's for primary keys! :)
Use a regular auto incrementing number, starting over at 1 for each story, and you'll have a much easier time transitioning software. (Plus you'll save (a little) on bandwidth.)
They only good reason I have ever heard of for using a GUID for a primary key is if you need to merge two databases, the GUID's will not collide.
No, that's not the problem. I would have the same problem if I used integer primary keys -- "/comments/4/87/98/293.txt". I would still have to somehow map that old scheme to my new one. (If I used the same storage system for my rewrite, my UUID keys would be fine; no need for integer primary keys.)
Additionally, the current version uses an immutable lockless storage system; if I had to increment keys I would have to lock. (The new version will also use UUIDs for the same reason.)
Look at my blog for example; with URIs like /comments/b31956d4-3dd1-11de-ba89-db8db9812c92/b5a70270-3dd1-11de-a405-db2750a175d7/b5a70270-3dd1-11de-a405-db2750a175d7.pod, it is going to be a nightmare to keep all links alive when I rewrite the software. In this case, I think I'm going to just kill them, since nobody links to individual comments. But I am not the NYT :)