List & Get Handlers

Part 1 built TaskStore: a mutex-guarded map with Create, Get, List, Update, and Delete methods. Chapter 1's Fundamentals HTTP work already covered writing JSON responses and decoding request bodies with encoding/json. This lesson connects the two — the first handlers that turn TaskStore methods into HTTP responses.

The server struct, and why it holds an interface

Every handler in this book is a method on server:

type server struct {
	store Store
}

Note the field type: Store, not *TaskStore. Store is an interface — Create, Get, List, Update, Delete — and *TaskStore happens to satisfy it. That distinction is easy to skim past, but it's the whole reason this chapter is structured the way it is. A handler that calls s.store.Get(id) doesn't know or care whether store is a map behind a mutex, a fake you built for a test, or a Postgres-backed type you write in six months. It only knows the interface's method set. Accept interfaces, return concrete types — you've likely met that guideline before; this is where it pays for itself. Later chapters can swap the store's implementation, or a test can hand server a stub that returns canned data, and not one handler signature changes.

For now newServer (in the hidden tests) wires up the real thing — &server{store: NewTaskStore()} — but the handlers themselves are written against Store, never against *TaskStore directly.

listTasks: the whole handler is one call

func (s *server) listTasks(w http.ResponseWriter, r *http.Request) {
	writeJSON(w, http.StatusOK, s.store.List())
}

That's it. s.store.List() already returns a []Task, writeJSON already knows how to set the header, write the status, and encode a value — the handler's only job is to wire the two together. There's no branching because there's nothing that can go wrong here: listing tasks always succeeds, even when there are none.

That "even when there are none" case is worth pausing on. Look back at TaskStore.List from Part 1:

out := make([]Task, 0, len(s.order))

make([]Task, 0, ...) — zero length, but non-nil. If List had instead started from var out []Task, an empty store would return a nil slice, and encoding/json marshals a nil slice as null, not []. To an API client, null and [] mean very different things — "something went wrong" versus "there's nothing here yet." That distinction was decided in Part 1, at the store, not here in the handler. listTasks gets the right behavior for free because the store was built correctly. It's another small payoff of keeping the store as a clean seam: get the contract right once, and every caller downstream inherits the correct behavior without having to think about it.

getTask: reading the path, mapping absence to 404

func (s *server) getTask(w http.ResponseWriter, r *http.Request) {
	t, ok := s.store.Get(r.PathValue("id"))
	if !ok {
		writeError(w, http.StatusNotFound, "task not found")
		return
	}
	writeJSON(w, http.StatusOK, t)
}

r.PathValue("id") reads the {id} segment out of the request's URL — the routing chapter in Fundamentals covered registering patterns like GET /tasks/{id} on a mux; this lesson only needs the value that produces, not the routing itself. Everything after that is the comma-ok pattern TaskStore.Get was built to support: ok tells getTask whether the lookup succeeded, and the handler's entire job is translating that boolean into an HTTP response. A hit becomes 200 with the task as JSON; a miss becomes 404 via writeError, which wraps the message in the same JSON error shape every handler in this book will use.

Notice what getTask does not do: it doesn't decide what "not found" means at the storage layer — that was TaskStore.Get's job, and it already returned a clean (Task, bool). The handler's only responsibility is the HTTP-shaped translation of that result. Keep that boundary in mind as the next lessons add the write side: createTask, updateTask, and deleteTask will each take the same shape — call the store, translate the result into a status code — with the interesting decisions (validation, what counts as invalid) living in the handler because, unlike existence, they're specific to HTTP.