mydigitalstructure & REST
REST sits above this and using hypermedia and some payload standards creates the "story" of the represented information via hyperlinks/links. mydigitalstructure has an single entry point that allows it to be consumed into a RESTful enviroment.
The REST client (eg web-browser, iPhone...) sends a request over HTTP/HTTPS to either:
Based on the Richardson Maturity Model, mydigitalstructure.com is a Level 2 service - although we do allow a developer to use a GET to change state if they choose.
We currently have a project underway to increase the maturity level of the mydigitalstructure REST interface.
You can use a hybrid rpc-rest methodology - eg getting not logged on response as a 401 http status. To do this, either:
Hypermedia as the Engine of Application State
- REST Tutorial / Best Practice
a must read!
- REST in Practice
a great read
- Restful Webservices
also a great read
- Explanation of Richardson Maturity Model by Martin Fowler
thank you Martin
- HTTP Methods
verbs: GET, POST, DELETE...
- HTTP Response Status Codes
- HAL - Hypermedia Application Language
a lean hypermedia type, application/hal+...
- POST to create
- PUT to update
- GET to search/retrieve
- DELETE to remove
- HEAD for object attributes (meta)
- HAL for linking & connectiveness
- Return format set by mediatype.
- Status codes used to augment OK/ER returns.
- 200/OK - default
- 201/Created - When a new object item is added via POST.
- 202/Accepted - when an object item is updated via PUT.
- 406/Not Acceptable - when mandatory data is missing or a model rule has be violated.
- 401/Not Authorised - when undefined mydigitalstructure method or not rights.
- 304/Not Modified - if ER with PUT on existing object item.
- 404/Not found - if GET on existing object item and not found.