You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
@Velocio
I have a question to developers about creating a Poll via an API.
There are two concepts/resources involved: The poll itself, and the collection of choices within a poll that people then would vote on.
What do you think you would prefer:
1) A single call to create the poll and poll choices, so that you have to construct the poll choice array and deal with whatever the interface issues of that are.
/polls/{id} would therefore return the poll and choices, and to add a choice you'd have to construct the entirety of the poll and PUT it to that address, likewise to remove a choice would also mean re-sending the whole poll.
2) 2 calls, 1 to create a poll and 1 to create the set of choices.
/polls/{id} would return a summary of the choices, but you'd only POST the poll question.
/polls/{id}/choices would be where you POST the array of choices, but you could individually POST new choices or DELETE an existing single choice by touching the choices at /polls/{id}/choices/{choiceId}.
3) Many calls, 1 to create a poll and 1 call for each choice you want to create/
/polls/{id} would return a summary of the choices, but you'd only POST the poll question.
/polls/{id}/choices would be where you POST the single new choice, and you could still individually POST new choices or DELETE an existing single choice by touching the choices at /polls/{id}/choices/{choiceId}.
We drafted the first version in the style of #1, but it created a few issues for UIs such as having to screw around with Django formsets and requiring the application to deal with the whole poll and all choices even if you only wanted to update or add a single choice. It also doesn't feel RESTful at all, it's clearly a mixed idea.
#3 seems like the purely RESTful way, but also feels like it's quite chatty and non-transactional (what if one fails, you have to figure that out and repeat that one call).
#2 feels like #3 but as it allows dealing with the choices in a RESTful way, but at the same time it allows you to deal with 2 transactional calls to create the poll... one for the poll, one for the choices.
So #1 we have... but it doesn't feel great. In the alpha #1 is likely to stay, but beyond that I'm curious as to what people would find easier to work with... #2? #3?