Adam Taft wrote:
Michael Terrington wrote:
Ordered does not necessarily mean hierarchical.
Hierarchy == Ordered, in my mind (particularly as it involves REST).
Agree, hierarchies are by their nature ordered.
I mean, if we're talking about Hierarchy in the object oriented frame of
mind (ie. "IS A" type hierarchy), then maybe you have something. But,
we're talking about something different. You're thinking about it more
in terms of passing parameters to a method, and I am thinking about it
more in terms of information organization.
No, I'm not thinking of parameters to a method. I'm thinking that a
hierarchical organisation implies parent-child relationships, which is
not the only kind of ordered relationship possible.
In this example, say I have a whole bunch of these translations in plain
text files. I don't have any other information beyond the "From" and
"To" languages (and maybe a unique identifier or timestamp), how am I
going to organize these on my hard drive?
I could store them all in one folder, with commas separating the
languages in each filename. Or, I can have a hierarchy of folders
organized per language. Like this (just to be silly):
Absolutely, either is valid. I prefer to keep related things at the
same level of hierarchy (i.e. the same folder).
The point of REST is NOT about ordered parameter passing. You have SOAP
for that. Instead, REST is about information organization, which is why
I like the slashes better since they're a better or more familiar
metaphor for organized data.
There's nothing in REST or the RFCs that forces a hierarchical
organisation on non-hierarchical data. The use of hierarchy in a URI to
me implies other resources may be available at other points in the
hierarchy.
By the way, this brought me to one more conclusion about the design of
the original poster's REST application. I think his new resource
reference URLs are wrong. In the example, he says that the new
reference is in the form of:
../jobs/8fc66aca2ae1aa792ea35b8012acb6
That's ok, but it could be better. It would be better by including the
unique key in the original POSTed hierarchy. Ie.
../jobs/en/de/8fc66aca2ae1aa792ea35b8012acb6
(assuming that the original POST was to ../jobs/en/de/)
I can't say I see that as any kind of improvement unless .../jobs/en/
and .../jobs/en/de/ are also resources you might want to address.
Regards,
Michael.
