Onlineweb API

Onlineweb4 exposes API endpoints.

API v1 is implemented using Django REST framework. All the endpoints in v1 are therefore browsable in a nice HTML-rendered GUI, with options for requesting json if wanted. This is done by modifying the ACCEPT: header. (read more) If at any time you have questions regarding how the API will react to requests, please consult the documentation for Django REST framework.

The current list of exposed endpoints can be found at /api/v1/. All endpoints are paginated, which means you will get max 10 results per page. To see a different page, follow the link supplied in the outer response body, named "next": "some.url/to/?page=2". Notice that detail views do not follow the same structure as list views.

The endpoints will themselves specify what HTTP methods they allow in all response headers. For convenience, this is also listed at each endpoint when browsing the HTML rendered version.

For endpoints which allow unsafe HTTP requests, you will be presented with an HTML form below the result set if you are allowed to POST to that endpoint. The API uses the customized django user model developed for Onlineweb 4 to authenticate, authorize and serialize users. Remember that PUT and DELETE requests require you to view the detail view of an object, e.g. PUT /api/v1/articles/1/. Refer to the HTTP Method Definition for more information.

At the time of writing (Nov. 1st, 2015) the endpoints only allow safe HTTP requests, such as GET, HEAD and OPTIONS.

DotKom documents the views, and you can see the documentation for each view at the top of the HTML rendered endpoint. Here you will get information about implemented filters and other useful information.

If you have implementation-specific questions, feel free to send an email to dotkom@online.ntnu.no or submit an issue.

---

API v0 used in onlineweb4 depends on tastypie.

The API can be found on url; /api/v0/

The API is segragated into versions, of which v0 is the version we have used pre-release. Updates to the api after release will demand the development of a new version of the api. No changes should ever be done to the API which includes stuctural changes which removes fields or changes the way information is retrieved.

If you wish to remove existing functionality, a new version of the API is needed.