24 Dec
2008
24 Dec
'08
1:03 p.m.
+1 to both issues.
Sergiu Dumitriu wrote:
Fabio Mancinelli wrote:
Sergiu Dumitriu wrote:
Not sure about this... At the protocol level,
AFAIK, query parameters are part of the URI an though they contribute to
identify the resource.
So, at this level, imho, it is almost a philosophical or best practice
matter.
Yes, it is. But the whole REST concept is a best practice on top of
something old. After all, it's just a way of using classic HTTP in a
special way. There are no hard validation rules yet, and the fact that
something is or isn't REST depends on the person you ask. And if you ask
me, the path is the identifier of the resource, while query parameters
and HTTP headers only influence the representation. So, is the
version/language a different representation of the same resource (the
document), or a whole different resource? This is also a philosophical
question, and we might have different opinions on this one, too. And the
answer depends on the involved content, too.
About the long URLs, many coding books suggest that longer, descriptive
names are better than very short ones. A name should be long enough to
describe what it holds, but from all the possibilities, the shorter ones
are preferable. Short, _understandable_ names. A URL is a name, too. We
should favor understandability over shortness.
I
don't like it since I'm not sure this is very RESTful.
+1, but it depends.
A resource is identified by the path, without query parameters.
Anyway I thought again about query parameters and
actually the main
reason why they are problematic is because apparently many caching
agents, by default, don't take into account query parameters. Squid, for
example, does so (but it can cache resources by using the full URI
http://foo/bar?param=value if configured properly).
So if we want to be sure that caching occurs, maybe it's best to
identify cacheable resources without using query parameters.
-Fabio