E. Wilde: REST Principles I: Identification and Uniform Interface

(2) Abstract

The two core constraints of REST are identification and a uniform interface. Starting from identification, we take a look at how the Web mixes identification with access, by using an identification scheme that not only supports decentralized and (mostly) anarchic growth. The Domain Name System (DNS) makes the growth at some level a bit more controlled, but as demonstrated by some TLDs (and ICANN's recent decision to sell new TLDs to the highest bidder), apart from the technical robustness, little else is stable about the way how the DNS is managed. Once identification and access are solved, the second important constrained coming into play is that of the uniform interface. In most real-life cases, this means that actual interactions in the application scenario are mapped to methods of the Hypertext Transfer Protocol (HTTP).

Identity and Naming

Outline (Identity and Naming)

Identity and Naming [4]
Naming and Context [2]
Identification and Access [3]

Identity and Naming E. Wilde: REST Principles I: Identification and Uniform Interface

(4) Things to Talk About

Physical things (objects, people)
Conceptual things (classifications)
Transactional things (orders, shipments)
Time should not play a role (lifetime is infinite)
Things can change over time (including changing between existing/non-existing)
Don't get philosophical: If you say something exists, it does!
Often things are members of classes of things (at least potentially)

Identity and Naming E. Wilde: REST Principles I: Identification and Uniform Interface

(5) How to Name Things

Identification does not imply naming
- naming becomes important in order to communicate
Naming should be based on context-free names in a shared namespace
- context-free means the ability to use a name wherever you like
- shared namespace means to stick to conventions
Names can have built-in semantics making understanding easier
- many person names have built-in semantics (origin, lineage, occupation)
- place names sometimes also help (12^th street, 1.-3. Altmatt [http://www.hls-dhs-dss.ch/textes/d/D7412.php])
REST only requires identification and nothing else
- using names that help to find the identified thing increases utility

Identity and Naming E. Wilde: REST Principles I: Identification and Uniform Interface

(6) Domain Name System (DNS)

Things on the Web must use a Uniform Resource Identifier (URI) [http://dret.net/lectures/web-fall10/uri]
Many URI schemes have naming authorities
- HTTP URIs have Domain Name System (DNS) names as part of the URI
- tel: URIs have GSTN country codes in them
DNS names allow to connect to a globally identified machine
- www.ischool.berkeley.edu identifies the www computer
- many DNS names can point to the same machine (virtual hosting)
- HTTP then only carries the path component of the URI
Anybody can add identified things to the Web
- add things within the URI path (server needs to respond)
- add a new server (DNS must point to real or virtual server)
- add a new subdomain (domain owner must add new DNS records)
- add a new TLD (start a country or pay ICANN a lot of money [http://www.icann.org/en/topics/new-gtld-program.htm])

Identity and Naming E. Wilde: REST Principles I: Identification and Uniform Interface

(7) Naming Authority

You can name your things any way you like
- using URIs will make sure they can be found on the Web
- using your domain name means you're in charge of running the server
- good URI design practices help to make URIs stable and helpful
How do things on the Web start their life?
- once the URI is minted, the server should start responding to it
- if nobody ever links to the URI, for all practical reasons it does not exist
- there is a large space of unlinked and thus unknown resources
Others linking to you increases your authority
- at an abstract level, this is the idea underlying PageRank [http://en.wikipedia.org/wiki/PageRank]
Others linking to you increases your responsibility
- other applications may depend on your things being available
- robustly designed applications should handle dead links gracefully

Naming and Context

Outline (Naming and Context)

Identity and Naming [4]
Naming and Context [2]
Identification and Access [3]

Naming and Context E. Wilde: REST Principles I: Identification and Uniform Interface

(9) Namespaces

There are social and technical assumptions around URI namespaces
- TLDs such as .edu are different from .com
- Web Security [http://dret.net/lectures/web-fall10/security] is very tightly coupled to domain names
DNS used to be more policed than it is today
- selling namespace real estate is a very lucrative business (e.g., .biz [http://www.neustarregistry.biz/])
- what about academia.edu [http://academia.edu/] and even berkeley.academia.edu [http://berkeley.academia.edu/]?
REST and federated naming allow scalable loose coupling
- new namespaces and names can be added without central coordination
- links work across all boundaries because of DNS lookups

Naming and Context E. Wilde: REST Principles I: Identification and Uniform Interface

(10) Context Matters

Many traditional organizing system design use context assumptions
- centrally managed resources/concepts such as classifications
- radically RESTifying them means to allow decentralization
- applications are still free to trust/distrust URIs they encounter
Library of Congress Classification [http://www.loc.gov/catdir/cpso/lcco/] does not seem to have actual URIs
- main classes are available as PDF [http://www.loc.gov/aba/cataloging/classification/lcco/lcco_t.pdf], Word Perfect [http://www.loc.gov/aba/cataloging/classification/lcco/lcco_t.wpd], or Word [http://www.loc.gov/aba/cataloging/classification/lcco/lcco_t.doc]
- identification of classification terms thus cannot be changed
- RDF [http://inkdroid.org/lcco/] is available but without any authority
Closed environments have trust built into them
- open environments need support for provenance and authenticity
- centralizing (parts of) the organizing system can make things easier to control

Identification and Access

Outline (Identification and Access)

Identity and Naming [4]
Naming and Context [2]
Identification and Access [3]

Identification and Access E. Wilde: REST Principles I: Identification and Uniform Interface

(12) How to Find Things

DNS allows to connect to the server hosting the thing
- IP does the hard job of getting packets across
- TCP does the hard job of making the connection reliable
- HTTP then has the easy job of just talking to the thing
DNS has some advanced trickery that sometimes helps a lot
- DNS lookup will return a different response based on your location
- a Content Delivery Network (CDN) [http://en.wikipedia.org/wiki/Content_delivery_network] then serves content from the best origin

Identification and Access E. Wilde: REST Principles I: Identification and Uniform Interface

(13) What to Do With Things

Some identifiers have global interaction schemes
- phone numbers (calling), addresses (visiting), fax number (faxing)
- but: what about SMS? easier in some countries because of mobile number prefixes
Identified things have application-level interaction semantics
- expect subcategories to be linked to from the category thing
- expect a book to be handed to you when following the get it link
Interactions in REST have three main constraints
- they use the uniform interface for the identification scheme
- they use self-describing representations (in request or response or both)
- representations will contain links allowing further interactions

Identification and Access E. Wilde: REST Principles I: Identification and Uniform Interface

(14) How to use HTTP?

HTTP has four main methods for interacting with resources
- GET retrieves a resource's representation (safe and idempotent)
- PUT requests to put a resource at a known URI (idempotent)
- DELETE removes a resource (idempotent)
- POST does everything else
Mapping RESTful application models to HTTP is a challenge
- all interactions must be based on HTTP's simple methods
- handing back and forth paper forms can serve as a good metaphor
- if a form can get lost and it doesn't matter: the operation is safe!
- if a form can get copied and it doesn't matter: the operation is idempotent!
- if a form must be delivered exactly once: use POST

REST Principles I: Identification and Uniform Interface

Principles and Patterns of Organizing Systems [./]
Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information
2011-03-08

Contents

(2) Abstract

Identity and Naming

Outline (Identity and Naming)

(4) Things to Talk About

(5) How to Name Things

(6) Domain Name System (DNS)

(7) Naming Authority

Naming and Context

Outline (Naming and Context)

(9) Namespaces

(10) Context Matters

Identification and Access

Outline (Identification and Access)

(12) How to Find Things

(13) What to Do With Things

(14) How to use HTTP?

(15) Conclusions

REST Principles I: Identification and Uniform Interface

Principles and Patterns of Organizing Systems [./]Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information2011-03-08

Contents

(2) Abstract

Identity and Naming

Outline (Identity and Naming)

(4) Things to Talk About

(5) How to Name Things

(6) Domain Name System (DNS)

(7) Naming Authority

Naming and Context

Outline (Naming and Context)

(9) Namespaces

(10) Context Matters

Identification and Access

Outline (Identification and Access)

(12) How to Find Things

(13) What to Do With Things

(14) How to use HTTP?

(15) Conclusions

Principles and Patterns of Organizing Systems [./]
Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information
2011-03-08