Upon receiving a 404 Not Found for John Smith??™s index of
papers published in 1997 at http://example.edu/~jsmith/papers/1997/index.html, it is
reasonable to expect http://example.edu/~jsmith/, if it exists, to be somehow associated
with John Smith.
URIs tend to self-organize into a hierarchy, in no small way due to their provenance
as filesystem paths. It is not a good idea to break users??™ expectations in this regard.
Although it may or may not be desirable for clients to always respect name opacity
(by only using URIs for dereferencing), it is certainly undesirable for servers to force
name opacity by creating inscrutable naming schemes.
Those who believe names should be opaque generally state that relationships
between URIs should be mined through links between resources. If a person (or
machine) retrieves a list of users (GET /users), the response would contain links to
each user in the list (/users/1, /users/2, ...). Commonsense as this may seem, especially
for a machine-consumable service, there are prominent RESTful web services
(such as Amazon S3, which we will examine later) that do not use links at all.
URI templates, described in an Internet Draft (http://www.ietf.org/internet-drafts/
draft-gregorio-uritemplate-02.txt), are a promising new hybrid between link-based
and hierarchical navigation. A URI template provides a structured pattern for URIs,
so that they make sense as hierarchies but can still be treated as opaque:
http://example.
Pages:
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301