Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SHOULD* use etags for DELETE to agents/activity APIs #564

Merged
merged 2 commits into from
Dec 30, 2014
+15 −11
Merged

SHOULD* use etags for DELETE to agents/activity APIs #564

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2eb1898
SHOULD* use etags for DELETE to agents/activity APIs
garemoko Dec 17, 2014
ca59e5b
DELETE is only If-Match. You can't delete nothing.
garemoko Dec 17, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 15 additions & 11 deletions xAPI.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2267,29 +2267,34 @@ of the problem.
### 6.3 Concurrency

##### Description
Concurrency control makes certain that an API consumer does not PUT or POST changes based on old
Concurrency control makes certain that an API consumer does not PUT, POST or DELETE documents based on old
data into an LRS.

##### Details
xAPI will use HTTP 1.1 entity tags ([ETags](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19))
to implement optimistic concurrency control in the portions of the API where PUT or POST may
overwrite existing data, being:
to implement optimistic concurrency control in the portions of the API where PUT, POST or DELETE may
overwrite or remove existing data, being:

* State API
* Agent Profile API
* Activity Profile API

The State API will permit PUT and POST requests without concurrency headers, since state conflicts
The State API will permit PUT, POST and DELETE requests without concurrency headers, since state conflicts
are unlikely. The requirements below only apply to Agent Profile API and Activity Profile API.



##### Client Requirements

* A Client using either Agent Profile API or Activity Profile API MUST include the
* A Client making a PUT request to either the Agent Profile API or Activity Profile API MUST include the
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO the text above this implied it only related to PUT, so I don't think we can argument POST/DELETE are MUSTs.

[If-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) header or the
[If-None-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26) header.

* A Client making a POST request to either the Agent Profile API or Activity Profile API SHOULD* include the
[If-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) header or the
[If-None-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26) header.

* A Client making a DELETE request to either the Agent Profile API or Activity Profile API SHOULD* include the
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DELETE doesn't need If-None-Match because you're not going to DELETE something that doesn't exist.

[If-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) header.

##### LRS Requirements

* An LRS responding to a GET request MUST add an ETag HTTP header to the response. (The reason for
Expand All @@ -2302,17 +2307,17 @@ of the SHA-1 digest of the contents.
modifications made after the consumer last fetched the document.
* An LRS responding to a PUT request MUST handle the [If-None-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26) header as described in RFC2616, HTTP 1.1 if it contains "*", in order to to detect
when there is a resource present that the consumer is not aware of.
* An LRS responding to a POST request SHOULD* handle the [If-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) header as described in RFC2616, HTTP 1.1 if it contains an ETag, in order to detect
* An LRS responding to a POST or DELETE request SHOULD* handle the [If-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24) header as described in RFC2616, HTTP 1.1 if it contains an ETag, in order to detect
modifications made after the consumer last fetched the document.
* An LRS responding to a POST request SHOULD* handle the [If-None-Match](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26) header as described in RFC2616, HTTP 1.1 if it contains "*", in order to to detect
when there is a resource present that the consumer is not aware of.

If the header precondition in any of the PUT request cases above fails, the LRS:
If the header precondition in either of the PUT request cases above fails, the LRS:

* MUST return HTTP status 412 "Precondition Failed".
* MUST NOT make a modification to the resource.

If the header precondition in any of the POST request cases above fails, the LRS:
If the header precondition in any of the POST or DELETE request cases above fails, the LRS:

* SHOULD* return HTTP status 412 "Precondition Failed".
* SHOULD* NOT make a modification to the resource.
Expand All @@ -2325,7 +2330,6 @@ If a PUT request is received without either header for a resource that already e
- set the "If-Match" header with the current ETag to resolve the conflict.
* MUST NOT make a modification to the resource.


<a name="security"/>

### 6.4 Security
Expand Down