Open-event-server: [Refactor] Allow direct post for endpoints of resources dependent on another resource

[shubham-padia]

@fossasia/open-event-server-devs
As opposed to what we are doing currently for related objects, most of the json-api clients use the direct post path for creating records (But they pass in the relationships in the payload)

For e.g. the clients use GET /v1/events/1/tickets only for getting the tickets for creating it, they use POST /v1/tickets and send the relationship (with event) as a part of the payload (jsonapi spec)
POST on /v1/tickets should only be possible if the event relationship data is available in the payload, else it should be rejected with a proper error.

The current implementation of post methods on /v1/events/1/tickets will be kept unchanged. After some of the refactor under this issue we can decide whether to keep them or not.

[enigmaeth]

@shubham-padia I don't get what you mean by the issue description. Current implementation to create ticket by POST on /v1/events/1/tickets throws an error when the event doesn't exist. If you mean that tickets be created by posting on /v1/tickets, why should that be?(Is it because jsonapi spec defines so? The punctuation is confusing). If not, I think that event/<int:event_id>/tickets would be better to let create tickets than /v1/tickets as that seems more logical to me( tickets related to an event), plus v1/tickets seems to look more like an admin-only accessible endpoint(like you want to list all the tickets).

[shubham-padia]

created by posting on /v1/tickets, why should that be?(Is it because jsonapi spec defines so?

It's because there was a misunderstanding earlier and it was now realised that most of the json-api clients follow this pattern :). @niranjan94 would be able to elaborate more on this.

[shubham-padia]

Just notifying: I'll add all the endpoints at once [except maybe a few], after that the documentation and testing can be added step by step in another parent issue

[niranjan94]

created by posting on /v1/tickets, why should that be?(Is it because jsonapi spec defines so?

Yes. An object's CRUD operations should primarily be on /objects endpoints and relationships are set by passing them along with the payload. That way, no relationship is automatically assumed and everything is explicitly set by the consumer.

The endpoints like /parents/<id>/object are used only for retrieving related records.

[niranjan94]

@shubham-padia also note, for all event related endpoints, make the existence of event relation compulsory. We really don't want any sessions, tickets etc in the db without any event attached to them,

[shubham-padia]

@niranjan94 regarding the old endpoints, they stop working after adding the new endpoints

What I propose is disable testing for all these POST endpoints,
make sure within few days that we are going ahead with this type of pattern only or not.

Instead If we are highly positive that we are going with this approach then sequentially we have to

• disable dredd for post endpoints
• add a duplicate resource list class for endpoints like events/id/tickets in each API and only allow GET there
• Edit existing POST request bodies in API docs
• and at last proceed to https://github.com/fossasia/open-event-orga-server/issues/4009

[niranjan94]

Our priority now is Endpoints like POST /v1/tickets. But it is compulsory that we have endpoints like GET /v1/events/<id>/tickets too.

Endpoints like POST /v1/events/<id>/tickets can be disabled for now if needed.