-
Notifications
You must be signed in to change notification settings - Fork 50
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.
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
Initial draft of the major area of the rest contract #4
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,100 @@ | ||
# Rest7Contract | ||
Repository to discuss the new REST API contract for DSpace 7 https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Working+Group | ||
Repository to discuss the new REST API contract for DSpace 7 <https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Working+Group> | ||
|
||
## Use of the HTTP Verbs and HTTP Response CODE | ||
|
||
### On collection of resources endpoints | ||
- POST | ||
Adds a new element to the collection. | ||
|
||
- GET | ||
Returns the first page of the resources in the collection | ||
|
||
### On single resource endpoints | ||
- GET | ||
Returns a single entity. | ||
|
||
- HEAD | ||
Returns whether the item resource is available. | ||
|
||
- PUT | ||
Replaces the state of the target resource with the supplied request body. | ||
|
||
- PATCH | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An example of PUT/PATCH would be useful to see. In particular, I am curious to see your thoughts for item updates. What components/relationships (metadata, item state, other relationships) would be handled by each http request type. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can use PATCH to update the value of a metadata without touch (and send) the information about the metadatafield, place, authority, etc. |
||
Similar to PUT but partially updating the resources state. | ||
|
||
- DELETE | ||
Deletes the resource exposed. | ||
|
||
### On sub-path of a single resource endpoint) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. List some of the sample paths. Item might be a good sample type. Can relationships also be conveyed in a PUT/PATCH request for an owning item, or are they always managed by an individual endpoint? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that we need to postpone this discussion to the specific endpoint. Not sure if it is possible make a general statement on that. PATCH is more likely to be able to work on relations as what is not specified is assumed untouched, PUT should replace anything that is allowed to set... |
||
- GET | ||
Returns the state of the association resource | ||
|
||
- PUT | ||
Binds the resource pointed to by the given URI(s) to the resource. Return 400 Bad Request if multiple URIs were given for a to-one-association | ||
|
||
- POST | ||
Only supported for collection associations. Adds a new element to the collection. | ||
|
||
- DELETE | ||
Unbinds the association. Return 405 Method Not Allowed if the association is non-optional | ||
|
||
### Error codes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 401 Unauthenticated and 403 Unauthorized could also be returned There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. you are right, these are enough general situation to be noted in this introduction instead to be hidden in the single endpoint documentation |
||
400 Bad Request - if multiple URIs were given for a to-one-association | ||
|
||
404 Not found - if the requested entity or collection doesn't exists | ||
|
||
405 Method Not Allowed - if the methods is not implemented or a DELETE methods is called on a non-optional association | ||
|
||
## HATEOAS & HAL | ||
The new REST DSpace API supports the HATEOAS paradigm and adopt the HAL format to express links and embedded resources. | ||
|
||
## Pagination | ||
Each endpoints that expose a collection of resources, including sub-paths for embedded or linked collections (aka list of items of a collection, etc.), MUST implement the pagination with the following common behavior | ||
|
||
### Request parameter | ||
- **page**: 0 based integer value that specify the requested page in the result set [default 0] | ||
- **size**: the dimension of the result set window to show. It must be a positive value. Negative or zero value must be rejected with a 400 Error code. The default value as well as maximum values are configurable by the system administrator. Different Maximum values apply for anonymous users, logged-in users and administrators. Size over the maximum value are automatically reset to the maximum allowed value, no error is thrown. | ||
- **sort**: the criteria to use. Ordering is specified appending a comma and the keyword asc or desc to the criteria name (i.e. title,asc). Unknown sort criteria and/or ordering keyword produce an error response with Http Code 400 | ||
|
||
### Response | ||
The HAL document always includes the following attributes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. HAL also returns a page object that contains the following properties: size, totalElements, totalPages, number. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. oops... I miss to list the attributes here :) I'm going to update the PR |
||
|
||
and, when applicable, the following links | ||
- **self**: a parameterized link to the requested collection page | ||
- **next**: the link to the next page of resources in the collection, if any, keeping the same option for size and sorting | ||
- **previous**: the link to the previous page of resources in the collection, if any, keeping the same option for size and sorting | ||
- **first**: the link to the first page of resources in the collection, keeping the same option for size and sorting | ||
- **last**: the link to the last page of resources in the collection, keeping the same option for size and sorting | ||
|
||
### Out of bound pages | ||
In the case that the request parameters lead to a page outside the result set an empty page should be returned with the links needed to go to the first and last page of the result set if the results set is not empty and the total number of resources in the collection | ||
|
||
### Error Code | ||
400 Bad Request. If an unknown sort criteria is requested or a not valid ordering keyword is specified | ||
|
||
## ETags & conditional headers | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What code will be responsible for generating/managing ETags? Is this provided by the framework, or will DSpace REST need to implement this? Where will an ETag be provided in a response? How will one be used in a subsequent request. An example would be useful here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It needs to be implemented in a common layer of our DSpace 7 REST API. I have created an issue for that https://jira.duraspace.org/browse/DS-3527 |
||
The ETag header (<http://tools.ietf.org/html/rfc7232#section-2.3>) provides a way to tag resources. This can prevent clients from overriding each other while also making it possible to reduce unnecessary calls. It is expected that all the returned document have an ETag | ||
|
||
The ETag value can be used with in GET request with the *If-None-Match* conditional header. If the header MATCHES the ETag, the API will conclude nothing has changed, and instead of sending a copy of the resource, an HTTP 304 Not Modified status code is returned. | ||
|
||
The ETag value can be also used with DELETE, POST, PUT and PATCH with the *If-Match* conditional header to avoid to perform action on changed resources (concurrency issues, optimistic lock approach). | ||
|
||
Finally, when possible the If-Modified-Since header in GET request should be respected. If the resource has been not modified since the value of the Header the API should return an | ||
HTTP 304 Not Modified status code. Resources that support the *If-Modified-Since* header *MUST* return the Last-Modified Header in the GET response, such header *MUST BE NOT* returned by resources not able to manage the If-Modified-Since header. | ||
|
||
## ALPS - Application Level Profile Semantics | ||
It is expected support for the ALPS metadata (<http://alps.io/>), so a profile link MUST exists from the root of API. | ||
A profile link as defined in RFC 6906 (<https://tools.ietf.org/html/rfc6906>), is a place to include application level details. The ALPS draft spec (http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-00) | ||
|
||
## Endpoints | ||
At the root of the api a HAL document MUST list all the primary endpoints allowing full discovery of the current version of the API. | ||
|
||
[Documentation of the defined endpoints](endpoints.md) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be useful to note a recommended mechanism for creating (1)a plugin that is intended for redistribution and (2)a local customization that an instance might develop. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is outside the scope of the REST contract. We need to document that as part of the REST 7 documentation for developers |
||
|
||
## API Versioning | ||
... here we will describe our strategy to provide access overtime to a specific version of the REST API... | ||
### Deprecated endpoints & methods | ||
... how we want to let know the client about deprecated endpoints & methods? | ||
### Experimentals endpoints & methods | ||
... do we want/need to introduce endpoints keeping the right to change behavior and other aspects without face with the self-imposed guarantee about backward compatibilty and versioning? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this checking for existence or is this a mechanism to check for authorization? An example would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have opened a dedicated issue to discuss that #5