I don't follow you. Here is an example of an "ugly" url
and the "pretty" version taken from wikipedia
Clearly the pretty version is much nicer.
0) The ".php" is redundant. This implies the implementation of this feature on the server is done in PHP. That is an implementation detail that should not have to appear in the API. Bad practice.
1) The "mod=" and "id=" are redundant. And who knows what "mod" and "id" or whatever other parameter means anyway? Useless noise.
2) The "?" and "%" are just ugly syntax,
I don't believe either style makes any difference to the programmer. It's just as easy to get those parameters either way. For example in node.js servers we might see:
Code: Select all
Where the routes.sample function gets at the params with:
Where as for the ugly style we have:
Or you can even get either style with this:
There is no need to put things in a hierarchy in either case although the pretty style demands that the params are given in the right order.
How data bases work is neither here nor there. Many databases use strings as keys. Some data bases can use complex objects as keys. A usere should not have to know or care if there is a numeric id used in the implementation of his account.
As an example the url of this post as I see it now could be:
http://www.raspberrypi.org/forum/post/r ... 9/#preview
Much nicer and with no impact on the programmer who has to handle it at the other end.
Producing "good" pretty urls is tricky
Actually I think designing a good API in either pretty or ugly styles is tricky.
But either way you go makes almost zero difference to the programmer.
Edit: However, there will be cases where it might be wise to use both path and query urls. Where the path identifies some resource you are accessing and the query params specify something about that query. For example when fetching a list of all users one might want to only get ten at a time so this would do it:
The general idea is that the path identifies some resource and the query params say something about the query on that resource.
Memory in C++ is a leaky abstraction .