Frontent API expectations

General Definitions

APITask here refers to APITask in /app/utils/task.ts, reproduced below for convenience. I am very open to tweaks/changes here.

type APITask = {
  uid: string;
  title: string;
  description: string;
  dueDate: number;
  occuranceRule: string;
  assignBy: string;
  assignableTo: string[];
  isCompleted?: boolean;
}

Task Management

/tasks

GET

Success:

{
    "tasks": [
        APITask,
        APITask,
        ...
    ]
}

/task

POST

Body:

{
    "task": APITask
}

Success:

{
    "task": APITask
}

Where idempotency is assured via task UUID. If the frontend submits a task without a UUID, how does the backend ensure idempotency?

I'm somewhat agnostic as to whether this APITask should have a UUID set by the frontend (meaning, we just rely on UUID4 mechanics to avoid collisions) or whether the frontend should send a null UUID and update the new task once the server responds with a UUID generated by the backend. I do think that we should either:

• have the frontend set the new task ID, and so remove /tasks POST in favor of /tasks/{id} PUT, or
• have the backend set the new task ID, and so remove /tasks/{id} PUT in favor of tasks POST

/tasks/{id}

GET

Success:

{
    "task": APITask
}

PUT

Body:

{
  "task": APITask
}

Success:

{
  "task": APITask
}

POST

Body:

{
  "task": APITask
}

Success:

{
    "task": APITask
}

Failure:

{
  "reason": Enum<TaskNotFound, MalformedTask, UserNotFound>
}

This route is for users to modify an existing task (new title / description / assignment). A task should be completed under /tasks/{id}/complete, but completed status may change at this endpoint when e.g. a task completion is "undone" in the frontend. TaskNotFound presumably exists on all /tasks/{id} routes, but this route may need to indicate that the update attempted to assign the task to a nonexistant user, or that the task payload was malformed.

DELETE

No body.

/tasks/{id}/complete

PUT

No body. Idempotency ensured by task and instance IDs?