API Design Decisions Explained

I've encountered interesting challenges while constructing this API. I felt this would be a good opportunity to jot down certain common questions building a REST API and include relevant explanations and justifications for their practices implemented here.

1. Asymmetrical Read-Write models - We create a user by just passing attributes such as {"name":"John Doe", "email":"[email protected]"} and other fields in the POST Request but in the Response, we also include certain fields such as id, created_at etc. Is including additional fields in a Response good practice?.
   Yes, it seems so: https://stackoverflow.com/a/28025008/6278404

2. Separate GET Endpoint despite bulk GET - There's GET events/ which could be made to accept an Id of the event as GET events/id=1 and would return a list of only one item containing event 1. However with PUT, PATCH and DELETE at events/:event-id, it made a lot of sense to also include GET event/:event-id so the Response format remained somewhat consistent for one object (a JSON object is returned instead of a list).

3. Absence of One-To-Many Relations in Django: Why is Hacker not in the Hackathon model and is the other way round? After all, it's /hackathons/<id>/hackers so a hacker should be a part of a Hackathon right? Unfortunately, Django does not provide support for One-To-Many relations. A good explanation of WHY Django doesn't have OneToMany relations can be found here: http://discuss.amir.rachum.com/t/a-case-for-a-onetomany-relationship-in-django/28/6 . TLDR: Creating DB Schemas for One-To-Many relations is convoluted, bad practice and hence Django gave up code readability for a reverse, more DB Friendly Many-To-One relation aka ForeignKey