Transition to using Django REST framework based API

[zzgvh]

RSR is moving from tastypie to Django REST framework (DRF) as the framework basis for its API. We will support the old tastypie API for as long as needed, but all, or at least most, new development should happen using DRF.

We are now adding location data to project updates and this requires changes to Up and its communicating with RSR.

For the reasons above I suggest that the DRF based API be used by Up, at a minimum for the new requirements, but ideally for all API use.

Overview of new requirements

A project update can now have one or more locations associated with it. At least initially there will only be one location per update, but the underlying models allow for an arbitrary number of locations.

An example of the XML format for posting an update with a location can be found here.

DRF uses header-based authentication, so instead of sending the API key in the query string it should be included in a header as follows:

Authorization: Token <api token>

The username is not needed.

Overview of transition of all of Up to DRF

Ideally all of Up should use the DRF based API. The RSR data is of course the same but the XML is formatted slightly different and thus needs changes in how Up interprets what's sent to it. An example of the XML can be seen here as a singe update and here a list of updates, but this is only the basic project update resource with the location in-lined.

I don't know exactly what calls Up does against the current tastypie API, so a list of that is needed for me to be able to build out what's needed in DRF.

[stellanl]

In summary, Up uses the old API for Projects, Updates, Users, Countries and Organisations, as well as logging in.
It now works to fetch updates through the DRF API. However, no filtering (on project ID) is happening, so I get all the updates times the number of projects.

[stellanl]

Now the /rest/v1/project_update API is used for submitting an update. However, since the DRF API does not return a convenient object-id header, I also need to parse the returned HTML body for it.

[stellanl]

Parsing now works. Only part missing is being able to verify an update by fetching it through the new API, using UUID as a filter.

[stellanl]

Only two calls to v1 API remain:

• User
• Organisation