[EMAIL PROTECTED] wrote:
Daniel,
First off: great post. I agree with your ideas and reading through this post
I realised I have tried implementing my URL space along these lines, ending
up with a huge and very unclear sitemap, so every improvement is welcome.
Nice, I had the same realization when I read Tim BL.
However, the example below is a bad one from a privacy/security POV:
Agree, I should have known better as we have worked quite a lot with
interview data for medical research at my company a few years ago.
The idea is that an URL identifies a resource. For the patient case
above it could be:
http://myhospital.com/person/123456789
In medical software your should always be aware that you will never expose
identifying information to unauthorized persons. Therefore the above URL
would be usable only in an environment where no unauthorized access to the
software or even view of the screen is possible.
Yes agree. My view is that access rights in most cases should be based
access right of the repository (or other) content that your resource is
constructed from, rather on being based on URL patterns. I wrote an RT
about that a number of years ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101282731120086&w=2
with current architecture the ideas in that RT is not that easy to
realize, but with my current proposal it would be easier.
Yes, I know that the first thing most medical software does is put some
identifying data of the patient on the screen (such as name, address, gender
and DOB) and often the ID in the current system as well. This is partly
necessary (except for the ID part), but it should never ever be part of a
cool URL that can be bookmarked or otherwise be addressed directly or stored
outside the application.
Besides the risk that unauthorized people read your bookmark list, using
the id is a bad idea , as people can use such URLs to query the system.
If you as a system designer wasn't paranoid enough people can learn
sensitive stuff from the difference between access denided and resource
not found messages.
/Daniel
In short, the ideas of cool URLs is great, but the implementation domain
might require otherwise.
Bye, Helma
