Get, Update & Delete a Task

What These Terms Mean

Sentinel error: a specific, predeclared error value that callers check for by identity rather than by parsing a message string. ErrNotFound is one example. The store returns it whenever an ID doesn't exist, and handlers compare against it using errors.Is. We first saw this pattern in Chapter 12.

204 No Content: the status code for "the request succeeded, and there is deliberately nothing to send back." DELETE uses it because there is no updated resource to return, unlike PUT, which returns 200 OK.

Full replace vs. partial update: PUT takes the request body and replaces the entire task with it. Any field you leave out is gone. A partial update, where you only change the fields you send, is what PATCH is for. We don't implement PATCH in this course, but it is worth knowing it exists for exactly that case.

Why These Status Codes

A missing task and a malformed ID are different failures, and clients need to tell them apart. 404 means "your request was well-formed, but nothing exists at that address." 400 means "I couldn't even understand your request." An ID like abc never reaches the store at all because strconv.Atoi fails before we look anything up.

The store and the handler split this work cleanly. Store.Get, Store.Update, and Store.Delete know nothing about HTTP. They just return ErrNotFound when a map lookup misses. The handler is the only place that knows ErrNotFound means 404. This is the same separation of concerns from Chapter 12. Errors are values the store hands back, and the handler decides what to do with them. If we ever added a CLI or a gRPC server on top of the same store, neither the sentinel error nor the store's logic would need to change. Only the mapping to a status code would change.

200 vs 204 follows a similar logic. GET and PUT both return 200 OK because they hand back a JSON body the caller can use. DELETE returns 204 No Content because after a task is gone, there is nothing left to describe.

The Store: Get, Update, Delete

internal/task/store.go adds a sentinel error and three new methods. All three are guarded by the same sync.Mutex as Create and List:

Get is a plain map lookup. The comma-ok form tells us whether the key exists, and we return ErrNotFound if it doesn't. Delete does the same check before calling the builtin delete on the map.

Update requires a closer look. It looks up the existing task first. That lookup is also how we check the task exists before overwriting anything. Then it copies existing.ID and existing.CreatedAt onto the incoming t before storing it. This makes PUT a full replace without accidentally changing a task's ID or creation time. The server always owns those two fields, no matter what the client sends.

store.go now imports errors for the sentinel, alongside the context, sync, and time imports from Chapter 20.

The Handler: get, update, delete

internal/task/handler.go registers the three new routes and adds get, update, and delete:

All three handlers start the same way. strconv.Atoi(r.PathValue("id")) turns the {id} wildcard from Chapter 16 into an int, and a conversion failure is an immediate 400. This is the id-parsing step that guards every route. The store never sees a non-numeric ID.

Past that point, each handler calls its store method and checks the returned error with errors.Is(err, ErrNotFound). A match means 404. Anything else falls through to 500 Internal Server Error. This fallback never actually happens with this in-memory store, but it will once a database can fail. This if errors.Is(...) { 404 } else { 500 } shape repeats three times because each handler owns exactly one HTTP decision, not because the logic is complicated.

update also decodes the request body the same way create does, then hands the decoded Task to Store.Update, which does the actual field-preserving work. delete has no body to decode. It just calls Store.Delete and, on success, writes w.WriteHeader(http.StatusNoContent) with nothing after it. There is no writeJSON call and no body. 204 means there is nothing to send.

One small naming note: the handler's delete method doesn't collide with the delete builtin used inside store.go. Methods live in a type's method set, not in package scope. This means h.delete and delete(s.tasks, id) are two entirely different things that happen to share a name.

Trying It With curl

Boot the server and create a task, just like in Chapter 20:

That gives you a task with id: 1. Now exercise all three new routes against it:

The GET /tasks/1 call finds the task and returns 200 with its full JSON. GET /tasks/999 returns 404 because no task has that ID. The PUT call sends a body with only title and done, leaving out description. The response drops description entirely, because a full replace means whatever you don't send is gone. The id and createdAt fields survive unchanged, exactly as Update promises. DELETE /tasks/1 returns 204 with an empty body, and GET /tasks/abc returns 400 before the store is ever touched.

Beginner Mistakes to Avoid

• Treating "not found" as success. It is tempting to let a missing ID fall through to a 200 with an empty or zero-valued body. A client checking response.ok would think the request worked. Always check the sentinel error and return 404 explicitly.
• Picking the wrong status for DELETE. Returning 200 with a body for a delete isn't wrong exactly, but there is nothing meaningful to put in that body. 204 says what actually happened: success, no content.
• Mutating a copy instead of the stored value. Update reads existing by value, not by reference. s.tasks[id] returns a copy of the Task struct. If you changed existing.Title directly, you would be modifying a local copy that gets thrown away, and nothing in the map would change. The code instead builds the final version on t (the decoded body) and assigns it back to s.tasks[id]. That assignment is the only line that actually updates the store.

What's Next

The in-memory CRUD API is now complete: create, list, get, update, delete. Chapter 22 adds request validation and a consistent JSON error shape, replacing the bare http.Error text we have been using since Chapter 20.