API definition

This page contains the basic API definition, including all routes, their methods, and the expected content-type and format of the body.

Basics

Since the backend should act as a REST-ful API, no state of any client may be saved on the server-side. Therefore no session ids will be used. Instead, the authentication is done for every request with the Google Sign-In API token.

Several possibilities exist for transmitting the Google Id Token:

• sending the token as part of the body: This would not work for GET requests and limit the format of request bodies
• sending the token as a cookie: This is not actually the intended use case for cookies, since those are usually set by the server and not by the client.
• using a custom HTTP header field: This seems to be the most promising option, since it provides enough flexibility and can easily be done in every request, without imposing any limits.

We should also try to make the API idempotent wherever possible, that means to use the correct HTTP methods (PUT is idempotent, while POST is not).

Required actions

In the following, some actions which might be required are listed. These actions do not take the inherent offline nature of the app into consideration.

User Management

• Acquire user information (name, profile pic, etc.) - GET
• Upload new profile picture - PUT

Group Management

• Create group - POST?
• Delete group - DELETE
• Change group info (name, picture, etc.) - PUT

Actually using the app

Personal space:

• Retrieve data from personal space - GET
• Create/modify data in personal space...

Groups:

• Retrieve data - GET
• Create new workouts - POST?
• Create new recipes

Missing information

• What data needs to be stored and modified in the personal space and in groups?
• For offline use: Where is the order of actions actually important?