Skip to content

Introduce controller layer and use it in the API

Nina requested to merge controller-refactor into release-4.0

This MR introduces a controller layer that is used in the routes to acces the model and the authorization. The idea is that this layer can later on also be used in the cli interface, so that the APIs might be more consistent but also easier to maintain, because some changes - e.g. authorization - only need to happen in one place.

I have tried to add missing request specs to avoid regressions - but probably not all corner cases are covered.

A few things are still missing:

  • The endpoint to update subscriptions via put is still missing a controller method.
  • Subscriptions can be retrieved via id and email. This is kind of cumbersome and I would really like to make this consistent by using only one identifier. For simplicity I have now only implemented the retrieval by id. We already have an issue for a API makeover #383 (closed) and I would like to tackle the implementation there, when have decided which way to go.
  • I found a bug in the subscription policy, that is fixed by !239 (merged) - this MR also contains some more specs for one endpoint. Listing subscriptions won't work until !239 (merged) is merged.
  • Clean up of the schleuder api daemon helper: A few methods can be removed when this whole thing is done.

But since we are already working in a release branch and not on master, I would prefer to some feedback sooner than later and will continue to work on the open to dos :).

Edited by Nina

Merge request reports