...
We'll be following (mostly) standard practice with HTTP methods for domain object CRUD:
...
- success: 201 CREATED with Location: "uri-of-created-resource", content: default representation of created object
- failure: 400 or 500
...
Action | URI | Outcomes |
|---|---|---|
Search | GET /ws/rest/patient?q=name+or+identifier | success |
...
= 200 OK with a list of minimal patient representations as content |
...
Create | POST /ws/rest/patient | success = 201 CREATED; Location: "uri-of-resource", content: default rep of created patient |
Retrieve | GET /ws/rest/patient/uuid.json | success: 200 OK |
...
; content: default json representation of patient |
...
= 404 NOT FOUND |
...
- like above, but a "full" representation (e.g. also containing a list of encounters)
Update | POST /ws/rest/patient/uuid |
...
|
...
= only properties |
...
you want to |
...
update, e.g. |
...
|
...
success |
...
= 204 NO CONTENT |
...
= 404 NOT FOUND |
...
= 400 or 500 |
Soft Delete |
...
DELETE /ws/rest/patient/uuid | success |
...
= 204 NO CONTENT |
...
|
...
= 404 NOT FOUND |
...
= 500 |
Hard Delete |
...
DELETE /ws/rest/patient/uuid?purge=true |
...
success |
...
= 204 NO CONTENT |
...
= 204 NO CONTENT |
...
|
...
= 400 or 500 |
...
Questions:
- Is it okay to use a POST to update only parts of a resource (instead of PUT with the complete object)?
- Is there a better way to expose the rarely-used Hard Delete method?
Our domain objects are often large (a patient and all their encounters and clinical observations), and contain lots of rarely-interesting book-keeping information (creator, date created, etc), and we expect many clients to be bandwidth-limited. Therefore we want to allow clients to fetch different representations of any resource. For example:
...