concrexit issueshttps://gitlab.science.ru.nl/thalia/concrexit/-/issues2018-01-21T23:15:25+01:00https://gitlab.science.ru.nl/thalia/concrexit/-/issues/56ThaliApp API2018-01-21T23:15:25+01:00Thom WiggersThaliApp APIAPI voor de ThaliApp
* InloggenAPI voor de ThaliApp
* InloggenLaunchWietse KuipersWietse Kuipershttps://gitlab.science.ru.nl/thalia/concrexit/-/issues/490Pizza API2017-10-03T15:47:57+02:00Gijs HendriksenPizza API### One-sentence description
Add the pizza module to the API (V2 I guess?)
### Desired behaviour
Add functionality to the API to view products, order pizza, change order, etc. from the ThaliApp. It is probably also nice to include admin...### One-sentence description
Add the pizza module to the API (V2 I guess?)
### Desired behaviour
Add functionality to the API to view products, order pizza, change order, etc. from the ThaliApp. It is probably also nice to include admin actions in the API, in case we want to perform admin actions through the app. Would be nice to implement this as soon as possible, both here and on the app side, so it can be used on one of the next drinks.
### Suggestion
I've thought a bit about how to make this as RESTful as possible. Thoughts are welcome.
* `GET https://thalia.nu/api/v2/pizzas/` to view pizzas (only if there is currently a PizzaEvent or if admin)
* `GET https://thalia.nu/api/v2/pizzas/event/` to view the current PizzaEvent (if there is one)
* `GET https://thalia.nu/api/v2/pizzas/orders/` to view all orders for the current event (only if admin)
* `GET https://thalia.nu/api/v2/pizzas/orders/[<id>|me]/` to view a specific order (only if yours or admin)
* `POST https://thalia.nu/api/v2/pizzas/orders/` to create a new order (with an optional body containing a name, for adding an order for non-members)
* `PUT https://thalia.nu/api/v2/pizzas/orders/[<id>|me]/` to edit a specific order, with a product id in the body, and (for admins) a paid field in the body (only if yours or admin)
* `DELETE https://thalia.nu/api/v2/pizzas/orders/[<id>|me]/` to cancel a specific order (only if yours or admin)
This is what I came up with, but maybe there is a better way?1.11Gijs HendriksenGijs Hendriksenhttps://gitlab.science.ru.nl/thalia/concrexit/-/issues/676APIs action decorator replaces list_route and detail_route2018-09-26T20:27:08+02:00Sébastiaan VersteegAPIs action decorator replaces list_route and detail_route/label ~"technical change" ~"priority: low"
### One-sentence description
APIs `action` decorator replaces `list_route` and `detail_route`
http://www.django-rest-framework.org/topics/3.8-announcement/#action-decorator-replaces-list_rou.../label ~"technical change" ~"priority: low"
### One-sentence description
APIs `action` decorator replaces `list_route` and `detail_route`
http://www.django-rest-framework.org/topics/3.8-announcement/#action-decorator-replaces-list_route-and-detail_route
### Why?
Deprecated
1.18https://gitlab.science.ru.nl/thalia/concrexit/-/issues/959API authentication returns 400 when providing the wrong credentials2019-11-06T20:58:05+01:00Gijs HendriksenAPI authentication returns 400 when providing the wrong credentials<!--
This template is for changes that do not affect the behaviour of the website.
** If you are not in the Technicie, there is a very high chance that you
should not use this template
Examples:
* Changes in CI...<!--
This template is for changes that do not affect the behaviour of the website.
** If you are not in the Technicie, there is a very high chance that you
should not use this template
Examples:
* Changes in CI
* Refactoring of code
* Technicie-facing documentation
-->
### One-sentence description
<!-- Please provide a brief description of the issue. Don't go into specifics. -->
The API `/token-auth/` returns a 400 status code when the user passed incorrect credentials, which makes it unclear why the request was denied.
### Why?
<!-- Please motivate why we should invest into this change -->
To make use of the correct HTTP status code, which could clarify the reason an authentication request was denied.
### Current implementation
<!-- If relevant, describe how it's done currently -->
`/token-auth/` returns a 400 when providing incorrect credentials
### Suggested implementation
<!-- Provide (a) suggestion(s) for how we could approach this -->
`/token-auth/` returns a 401(?) when providing incorrect credentialsSimcha van CollemSimcha van Collemhttps://gitlab.science.ru.nl/thalia/concrexit/-/issues/441Add register/cancel to event API2017-12-10T21:11:19+01:00Sébastiaan VersteegAdd register/cancel to event API### One-sentence description
Add register/cancel to event API
### Discussion
Het zou prachtig zijn als je je via de ThaliApp zou kunnen aanmelden voor evenementen. Nu is dit niet alleen een geavanceerde functionaliteit, maar ook e...### One-sentence description
Add register/cancel to event API
### Discussion
Het zou prachtig zijn als je je via de ThaliApp zou kunnen aanmelden voor evenementen. Nu is dit niet alleen een geavanceerde functionaliteit, maar ook een moeilijke omdat er veel business logic voor nodig is.
Op dit moment hebben we een simpele REST API waarmee gegevens over evenementen en registraties kunnen worden opgehaald.
Dit werkt erg goed, maar geeft nog geen fancy mogelijkheden.
Maar we hebben twee discussies die we wat mij betreft even moeten tackelen zodat goed is nagedacht over de implementatie. De twee problemen staan hieronder en ik ben benieuwd hoe jullie hierover denken.
#### Probleem 1: DRY
Stel we willen de mogelijkheid tot aanmelden toevoegen aan de API dan zal de events app een refactor moeten ondergaan, aangezien we anders de business logic op twéé plekken moeten doen: `views.py` en `api/viewsets.py`. Nu weet ik niet wat de beste manier is om dit te doen, maar het beste lijkt me om een `services.py` toe te voegen die de business logic uitvoert. Ongeveer zoals [hier](https://stackoverflow.com/a/12857584/1074080) beschreven wordt. Die `services.py` doet dan alle business logic die dan weer gebruikt kan worden in de views. Voordeel is dat zo’n `services.py` apart getest kan worden en we geen code gaan herhalen. Maar het kan natuurlijk zijn dat er betere manieren zijn om dit te doen, dus ideeën zijn welkom.
#### Probleem 2: REST
Aangezien we Django _REST_ Framework gebruiken zou het natuurlijk mooi zijn als we een superduper fancy RESTful API zouden neerzetten. Basic REST is makkelijk: dingen ophalen met GET, dingen aanmaken met POST, dingen aanpassen met PUT/PATCH en dingen verwijderen met DELETE.
Een simpele API zou je dus eigenlijk zo kunnen doen:
```
POST /events/1/registrations met een optionele body die de fields bevat -> Aanmelden voor event
PUT /registrations/<id>/ met required body die de fields bevat -> Aanpassing registratie
DELETE /registrations/<id>/ -> Registratie verwijderen = Afmelden voor event
```
_Maar_ dat wil je eigenlijk **niet**. DELETE zou namelijk niet echt iets verwijderen, dat past enkel de cancellation date van de registratie aan. En dan kun je die niet meer gebruiken als je daadwerkelijk dingen wilt verwijderen (zoals in-app event management oid). Dus laten we deze optie vooral niet gebruiken.
- - -
Een tweede, betere optie ([info over PATCH] (http://restcookbook.com/HTTP%20Methods/patch/)):
```
POST /events/1/registrations met een optionele body die de fields bevat -> Aanmelden voor event
GET /registrations/<id>/fields -> Verkrijg velde en huidige waardes (initial state zou dus velden met default values zijn)
PUT /registrations/<id>/fields met required body die de fields bevat -> Aanpassing registratie
PATCH /registrations/<id>/ met {“is_cancelled”: true} body -> Afmelden voor event
PATCH /registrations/<id>/ met {“is_cancelled”: false} body -> Weer aanmelden voor event na afmelding
```
Nadeel hiervan is dat het eigenlijk wel veel werk is in de app:
Stel je meld je aan dan moet POST worden gedaan, bij een cancel gaat het met PATCH.
Maar als je je dan weer wilt aanmelden dan is dat geen POST maar een PATCH.
- - -
En dan hebben we nog een derde optie die minder REST is ([want: verbs are bad](apigee.com/about/blog/technology/restful-api-design-nouns-are-good-verbs-are-bad)):
```
POST /events/1/registrations/register met een optionele body die de fields bevat -> Aanmelden voor event
POST /events/1/registrations/update met een optionele body die de fields bevat -> Aanpassing registratie
POST /events/1/registrations/cancel zonder body -> Afmelden voor event
```
Dit is niet echt REST, maar wel het makkelijkst te maken aangezien onze huidige structuur voor de normale view eigenlijk ongeveer hetzelfde in elkaar zit.
- - -
Er zijn nog wel meer opties te bedenken, dus als er iets beters is dan zijn ook hiervoor ideeën welkom. Ik heb persoonlijk een voorkeur voor optie 2.Sébastiaan VersteegSébastiaan Versteeghttps://gitlab.science.ru.nl/thalia/concrexit/-/issues/352API toevoegen zodat phocabby photos automatisch geupload kunnen worden2019-05-27T22:17:39+02:00Luuk ScholtenAPI toevoegen zodat phocabby photos automatisch geupload kunnen wordenNils stuurde het volgende:
> Zoals jullie wellicht weten, wordt mijn phocabby gedoneerd aan Thalia. Het zou erg handig zijn als de website een REST-api krijgt waar de foto's naartoe gepost kunnen worden. Dan kan ik de facebook-uploade...Nils stuurde het volgende:
> Zoals jullie wellicht weten, wordt mijn phocabby gedoneerd aan Thalia. Het zou erg handig zijn als de website een REST-api krijgt waar de foto's naartoe gepost kunnen worden. Dan kan ik de facebook-uploader aanpassen, zodat gemaakte foto's niet meteen publiek te bezichtigen zijn. Staat er al zoiets in de planning, en zo ja, wanneer is dat af?
> Mijn doe-het-zelfie bepaalt zelf hoe een album gaat heten en maakt die dan aan als die nog niet bestaat. Dat album heeft als naam bv 'donderdag 2 maart' en bevat in dat geval de foto's van 2-3-2017 06.00 - 3-3-2017 06.00. Die functionaliteit kunnen jullie indien gewenst ook zelf inbouwen, zodat het apparaat alleen nog maar foto's hoeft te bufferen en posten als er een netwerkverbinding is. Eventueel kan ik zelf ook wel iets bijdragen in het bouwen van een dergelijke api.
> Een andere optie is het posten naar een besloten facebook-groep. De foto's kunnen dan niet meer op de website geplaatst worden door reeds bestaande policies.