Communications of the ACM

ing computation and work as modifications to the representation. It’s REST or changes to the representation that cause change.

Every verb (operation) can be
nouned (cast as data).
These nouns are described as URLs.
Operations are cast into identities
represented at URLs.

Identity is RESTing on its laurels. The identity captured in the URL is a large part of why REST is so powerful. The underlying resource has an identity in the URL namespace. Each representation (assigned to a single user) has an identity in the URL namespace. Specific operations are captured, leveraging identity within the URL namespace—a powerful mechanism using the identity of the URL!

Scoping Identity

Identities must be scoped in space and time so they do not cause ambigui-ties. This is, on the one hand, an obvious and silly thing to say. On the other hand, it is a liberating concept.

Identifiers may have permanent unique IDs like those offered by UUIDs. These are powerful and useful. Identifiers may have a centralized or hierarchical authority that assigns their IDs, and that, by itself, offers challenges: Does this authority scale? Is it broad enough in its role to encompass the many different pieces of the solution?

The reality for most systems is that identities span the participants that see the use of that specific identifier. When merchants interact with a big e-commerce site, they will have shared identifiers for their cooperative work. Still, the merchants may not share the identifiers they use to deal with private suppliers. Those private suppliers may have different identifiers used to interact with the manufacturers of their products.

The scope of the identifiers is typically subject to the portion of the workflow that hosts the identifier. There are global IDs like UPC or SSN (Social Security number), but there are also local IDs like SKUs that are defined only for a single merchant.

The ‘I’s Have It

Identity is an extremely important
part of our systems. Its real power is
unleashed when combined with three
tional state transfer3 (REST) is an in-
teresting and influential pattern that
leverages HTTP and URLs. In the REST
pattern, resources are implemented as
client-server calls, which are stateless.
Stateless means each request from the
client holds enough information to
process the request at the server with-
out taking advantage of any context
stored at the server. The session state is
effectively held at the client.

Resources and representations. Within REST, resources are any piece of information that can be named. Typically, the name of a resource is a URL. 1 A resource is frequently used to represent groupings of related stuff that may be used to do work. The contents of a resource may be static or dynamic. What is essential is that it can be named.

REST resources may project one or more representations. Each representation is a view onto the resource that may or may not be customized for each user. The resource is itself given its own URL(s) as identities.

RES T: Representational state transfer. Users wishing to work with the resource are given their own representations as identified with one or more URLs. The resource may have many users. The vast URL identity space is subdivided into representations for each user. Requests for work are accomplished with HTTP PUT commands making modifications to the representation.

Scribbling on the representation. Changing the state projected in the representation is how work is done. The combination of the representation (possibly personalized to the client) and the ability to scribble changes on the representation allows many clients to work with the resource.

URL: Mixing identity, operations, and session state. As changes to the representation occur, responses to the HTTP PUT requests are wrapped up in the URL returned. Contained in that URL is the session state describing ongoing and potentially long-running work for this client.