[uf-discuss] "Lightweight Data Access Services" and Well Designed Urls

Tue Oct 17 01:20:40 PDT 2006

Karl:

Many thanks for commenting.

>> BUT be careful of Well Known Location issues.

Can you give me examples? I googled "Well Known Location" and didn't find
anything that seemed relevent.

>> Trying to standardize URLs would be very bad by limiting the choices of
users.

I don't think I'm trying to standardize URLs per se. I'm instead trying to
collect up, codify, and recommend patterns and practices.

Since you commented, did you read this first?
http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx  Do you
see recommendations there that you think will cause problems? (Be aware that
it's been 16 months since I wrote that and am really ready to revise it.)

What I do want to do is shine a light on the cons of various choices for web
site developers as well as platform developers (Microsoft is one in need of
hearing this message.)

As an aside, I think limiting choice can be good (if you have ever eaten at
TGI Fridays, I'm sure you will relate to that comment!) Too much choice
creates chaos and allows inexperienced people to make really sub-optimal
choices for no other reason than happenstance. Best practices call out where
the pitfalls are, and how best to avoid them.  If all choice was good all
the time there would never be any use for Best Practices for anything,
right?

>> As an example Link Ranking Systems have increased spam on the Web and
nofollow didn't solve it at all.

I think the things I'm thinking about as best practices are not of the same
as the types you are talking about. I planning to codify those things that
will make it easier for users to work with URLs; I'm not trying to create a
new "layer" on the web or any new "standards", only "patterns".  And nothing
like Link Ranking Systems or nofollow. 

For example:

* Once published, don't move the content to another URL
* But if you move it, always leave a 301 or 302 redirect when you move a URL
* Don't change the meaning of content at a published URL (with caveats, to
be later discussed)
* Ideally don't use extensions for (X)HTML content.
* If you must use an extension for (X)HTML content, use either .HTM or .HTML
* Extensions on URLs should define the content, not the technology that was
used to create the content (i.e. .HTML not .ASPX, .JPG not .PHP, etc.)
* When you peel off a subdirectory from a URL it should return a valid and
appropriate .HTML page 
* Avoid using "magic numbers" in URLs whenever possible (i.e. use
www.mysite.com/cars/ not www.mysite.com/5/) 
* A URL with a trailing slash should equal a URL w/o a trailing slash.
(i.e. www.mysite.com/foo should be the same as www.mysite.com/foo/)
* Organize major site divisions by subdomain (I need to put a lot more
thought into this one about when and when not to)
* Sitemaps and Website URL structures should have a very tight coorelation.
* For new websites and website redesign, design your URL structure as one of
the first steps.
* Plus a *LOT* more...

Also, please let's not debate these specific examples HERE (unless they are
of the *type* that you caution me about); that's what the blog, list, and
wiki are for, and besides I'm writing these on the fly and have not fully
fleshed them out yet.  I don't want to impose too much more on this list.

BTW, some of the above it is VERY DIFFICULT to do in Microsoft IIS (until
version 7.0) and many commercial web applications and content management
systems) do a horrific job related to providing clean URLs  (i.e. Vignette,
DotNetNuke, etc.). However to date there's been no set best practices so the
platform developers are like Alfred E. Newman and they say "What, me worry?"
;-)   I want to give them something that says "What you are doing when you
are not considering your URL structure is creating all kind of problems for
all kinds of people and here is why you need to think about your URL design
and not consider the URLs your apps create to be just your own private
Idaho."  I also want to give Windows-centric hosting companies more reasons
empower users to clean up their apps URLs.  And more.  (I hope you undersood
my two potentially American-centric puns above. :)

This is much more about shining a light into a problem area / area of
opportunity than it is specifying some new set of standards.  Think of it as
similar to Jesse Jame Garrett and his declaration of AJAX (though I could
only wish to be that influencial.)  Jesse didn't defined any new standard
with AJAX, he just applied a name to an existing set of technologies and
recommend a set of patterns for how they can be used.  So like Jesse, I'm
more proposing *PATTERNS*and not *STANDARDS*.  Make sense?

>> Microformats have a "poor man namespace" mechanism which is the profile
in the head. It helps people using the same class names to be free to use
them without the same semantic (with the hope that search engines, do not
index microformats not properly identified by the profile.)

I'm not seeing how this relates to URL design per se.

Also, are you considering Microformats only valuable for search engines?  

>> Do not confuse Web Architecture with URLs. That's the part which is not
understood from REST Web architecture style.

I'm not sure I can confuse them yet because I don't really know what "Web
Architecture" is other than a highly abstract term used to describe the
collective technology architecture for all that is the web. Is is mean
something else to which I am just ignorant?

>> I encourage your to read this excellent series of posts by Joe Gregorio
http://www.oreillynet.com/tags.csp?tag=rest 

I reviewed these but didn't find anything that was new to me as I've been
collecting articles about REST and about building APIs. I include them so
you can see my influences:

About REST for Web Services
*	Building Web Services the REST Way
<http://www.xfront.com/REST-Web-Services.html>  
*	REST: Simplicity in Web Services design
<http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1148486,00.ht
ml>  
*	Representational State Transfer (REST)
<http://en.wikipedia.org/wiki/Representational_State_Transfer>  at Wikipedia
orld <http://www.infoworld.com/> 

How to Build an API
*	How to Design a Good API and Why it Matters
<http://lcsd05.cs.tamu.edu/slides/keynote.pdf>  
*	How to design Good APIs and Why they Matter
<http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=325815
8706>  
*	How To Provide A Web API
<http://www.sourcelabs.com/blogs/ajb/2006/08/how_to_provide_a_web_api.html>

*	How to Add an API to your Web Service
<http://particletree.com/features/how-to-add-an-api-to-your-web-service/>  
*	Simple API Design
<http://loudcarrot.com/Blogs/dave/archive/2004/09/26/552.aspx>  
*	How To Design a (module) API
<http://openide.netbeans.org/tutorial/api-design.html%20>  

I am going to print and read your articles just in case I missed some things
while scanning them over.

I'm anxious to know your thoughts based on my clarification.  Also, would
there be sufficient interest for me to start a list now, and invite anyone
interested to come on over?  I'll need 5-10 interested parties otherwise it
won't be time yet.

-Mike Schinkel
http://www.mikeschinkel.com/blog
http://www.welldesignedurls.org/

P.S. I've also rethought the name "Casual Web Services" and think that is
not the best. I'm now thinking "Lightweight Data Access Services." (I
changed the subject to recognize that.) Actually, I have an even more
creative meme for it, but I'm not ready to reveal that yet. ;)

-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Karl
Dubost
Sent: Tuesday, October 17, 2006 1:27 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] "Casual Web Services" and Well Designed Urls 

Le 14 oct. 2006 à 18:02, Mike Schinkel a écrit :
> I recently started working on a project I'm calling "Well Designed 
> Urls"
> (http:///www.welldesignedurls.org/) that has been a pet issue of mine 
> for a long time. See my Aug 2005 blog post:
>
>    http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx
>

There are interesting things in your post BUT be careful of Well Known
Location issues.
Trying to standardize URLs would be very bad by limiting the choices of
users.
In these cases, there is a balance between what do we improve and what are
the problems we create in the ecosystem. As an example Link Ranking Systems
have increased spam on the Web and nofollow didn't solve it at all.
Microformats have a "poor man namespace" mechanism which is the profile in
the head. It helps people using the same class names to be free to use them
without the same semantic (with the hope that search engines, do not index
microformats not properly identified by the
profile.)

Do not confuse Web Architecture with URLs. That's the part which is not
understood from REST Web architecture style.
I encourage your to read this excellent series of posts by Joe Gregorio
http://www.oreillynet.com/tags.csp?tag=rest

--
Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA
Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss