I decided to forego a DELETE method for /tasks or /tasks/id. Instead, tasks can be archived and all tasks, archived or not, are still provided upon GETs. The client decides what to do with the archived tasks. I took this approach after noticing that Trello doesn't seem to encourage task deletion and even goes as far to offer an Undo for nearly everything (which I'd like to look into replicating!).
As closely as possible, I tried to emulate the table of method responsibilities described in this Microsoft article. Likewise, I try to have all endpoints returning appropriate error messages for methods used.
- Modeled as a collection
- Modeled as a resource
I decided to register the all API related functionality in a blueprint. I think this makes the most sense because it's easily namespaced. Were I more forward thinking, I would version the blueprint name and containing api package to something like apiV1 to avoid future headaches.
- A
task_descriptionfield exists on each task but is unused by the client.
init-dbwipes the old db and reapplies the schema inschema.sql.fill-db <qty>runsinit-dband uses Faker to generate<qty>tasks with randomized completion status, titles, and descriptions (they are all unarchived, however).
make_public_task(task)returns a dict of the task that's presentable for responses. This entails boolean coercion from the integer 1s and 0s in the db (sqlite uses integers for bool values) and convertingtask_idto a unique URI keyed astask_uri. In the futuremake_public_task()may mask certain attributes that shouldn't be given to the client.