Skip to content

restructure API

Bengfort requested to merge api-restructure into main

basis for API addition (see !2182 (merged) and !2183 (merged))

I was thinking about a lot of different options:

For the setting the question was whether there should be a single global setting or one setting per app. I went with the former option because it is simpler (which also means that is has less potential for errors).

For the URL structure there were many options, e.g.:

  1. /<app>/<id>/api/…
  2. /<app>/api/<id>/…
  3. /<app>/api/<model>/<id>/…
  4. /api/<app>/<id>/…
  5. /api/<app>/<model>/<id>/…
  6. /api/<model>/<id>/…

(1) was what we did before (see !1919 (merged)). It was intentionally very inflexible to narrow the potential for security issues. With the new requirements this is no longer feasible.

(3) is what I ended up with. It is very verbose (e.g. /subjects/api/subjects/{domain}/{pseudonym}/attributes/) but flexible. I kept the APIs in their respective apps mostly because it is easier to implement in our current structure.

In a way deciding on a URL structure is not that important because in the end they will all work. However, every change to this structure is a breaking change with a potentially big impact. So we should try to settle on something that we can use for the foreseeable future.

Edited by Bengfort

Merge request reports