Delete and Error Semantics

Delete and Error Semantics 204 deletion, missing rows, and honest HTTP meaning

Phase 11 - Persistent Task CRUD API Volume 03 - Database Engineering

Architecture milestone DELETE /tasks/:id

↓

Prisma delete

↓

204 or 404

Phase 11 replaces process memory with durable PostgreSQL-backed application behavior.

DELETE /tasks/:id - remove a durable row Deletion is a useful place to separate database return values from HTTP response semantics. Prisma can return the deleted row internally, while the HTTP endpoint can intentionally return 204 No Content.

@Delete(":id")
@HttpCode(HttpStatus.NO_CONTENT)
async remove(@Param("id") id: string) {
await this.tasksService.remove(id);
}

async remove(id: string) {
try {
return await this.prisma.task.delete({
where: { id },
});
} catch (error) {
this.rethrowMissingTask(error, id);
}
}

Test deletion PowerShell can expose the HTTP status directly with Invoke-WebRequest:

$response = Invoke-WebRequest ` -Method Delete ` -Uri "http://127.0.0.1:4000/tasks/$taskId"

$response.StatusCode

Expected result

204 means the request succeeded and there is intentionally no response body. A later GET for the same id should return 404.

Error mapping is not a global architecture yet Phase 11 handles the one Prisma error needed for CRUD semantics close to TasksService. Phase 13 will introduce a more systematic error strategy and exception mapping. We do not build a giant global abstraction before there is enough repeated behavior to justify one.

Situation HTTP meaning Current handling

Task does not exist 404 Not Found NotFoundException

Create succeeds 201 Created Nest POST default

Read/update succeeds 200 OK Nest default

Delete succeeds 204 No Content Explicit @HttpCode

Malformed body Not robust yet Phase 12

Unexpected database failure 500-class failure Propagates to Nest

Do not turn every database error into 400 A timeout, connection failure, constraint violation, and missing row are not the same condition. Error handling should preserve meaning. If the application cannot classify an unexpected failure safely, it should not fabricate a friendly-but-wrong status code.