UserPreferences

PaceURINomenclature


Abstract

Regarding Draft protocol-09

Status

In play

Rationale

Cleanup for "Member" and "Edit" URIs, and clarify which is found where.

Proposal

5.2

Section 5.3, rewrite

Once a resource has been created it can be retrieved, updated, or deleted. The URI used to retrieve it is called the "Member URI" and that used to update it the "Edit URI". They may be the same.

5.3.2

5.3.3

Create new section 8.1, causing 8.* sections to shuffle down

8.1 Member and Edit URIs

In the Atom Publishing Protocol, a resource is identified by (potentially) two different URIs, referred to as the Edit URI and the Member URI. The Member URI is expected to yield a representation in the form of an Atom Entry. The Edit URI is expected to support updating and deleting the resource via the use of PUT and DELETE as described in this section.

The Member and Edit URIs may be the same URI, but client software MUST NOT rely on this.

The Edit URI may respond to GET requests, but client software MUST NOT rely on this.

In the APP, Member URIs appear in two places: returned in a Location header after successful resource creation using POST, as described below, and in member entries of a collection, in an atom:link element with a link relation of "self". Edit URIs appear in member entries of a collection, in an atom:link element with a link relation of "edit". Each member Entry within a collection SHOULD contain such an atom:link element providing an Edit URI.

(section numbers from here down are the original section-8 numbers, pre-shuffle)

In section 8.1:

2nd para: "... received in the POST, its Member URI MUST be..."

3rd para: "... if, provided, MUST be an Atom Entry Document representing the newly-created resource, and SHOULD include its Edit URI in an atom:link element with a link relation of "edit".

Delete 2nd-last paragraph beginning "Clients MUST NOT assume..."

In section 8.2:

2nd para after first example: "The response includes a "Location" header indicating the Member URI of..."

Delete section 8.3, it's covered above in the new section 8.1

In Section 8.4:

First para: "... and return its member URI."

2nd para: ".. the Location header included in the response MUST be the Member URI of the media link entry"

In section 8.4.2:

Para beginning "THe server signals...": "The response includes a "Location" header indicating the Member URI of the media link entry..."

In Section 9:

3rd para: "... and should perform a GET on the resource's Member URI before editing"

Impacts

Notes


CategoryProposals