What You Will Build

There are a few things worth noticing here, because they will come back later.

The verb carries the intent. GET reads, POST creates, PUT replaces, and DELETE removes. The path names what you are acting on. The verb says what to do with it. This is the core idea of REST.

The {id} in three of the paths is a placeholder for a real task's ID, such as GET /tasks/42. Notice that the exact same path does a different thing depending on the verb used. Routing these requests to the right place is an important topic, so it gets its own chapter later.

The status codes are not interchangeable. Creating a task returns 201 to indicate something new exists. A successful read or update returns 200 to hand back the result. Deleting a task returns 204 to say the action worked, but there is no data to send back. Choosing the right status code is part of building an API that other developers can trust. We will be deliberate about it.

The Task resource

Every task the API stores and returns looks like this:

Here is what those fields mean:

• id — a unique number the server assigns when the task is created. The client never picks it.
• title — a short summary of the task. This is the only required field.
• description — optional longer detail. It can be left empty.
• done — true or false, indicating whether the task is finished. New tasks usually start as false.
• createdAt — a timestamp set by the server when the task is created, using the standard UTC format shown above.

Notice that the server owns the id and createdAt fields, not the client. When you create a task, you do not send those values. The server fills them in and hands the complete task back to you. This keeps IDs unique and timestamps honest. It is a small design decision that pays off when we write the create endpoint.

A create request, end to end

To make the JSON concrete, here is what creating a task looks like from both sides.

You send a POST request to /tasks with just the fields you control:

The server stores the task and replies with a 201 Created status code. It also returns the full task, which now includes the id, the done flag defaulted to false, and the createdAt timestamp it generated:

That round trip of JSON in and JSON out is the heartbeat of the whole service. Every endpoint is just a variation on this pattern.

How a request flows through the service

When a request arrives, it does not hit one giant block of code. It passes through a few clear layers, and each layer has one specific job. Keeping these layers separate is what makes the service easy to test and easy to change later.

Reading from left to right:

• Client — whatever made the request. This could be curl, a web browser, or a mobile app. It sends an HTTP request and waits for a response.
• HTTP server — Go's built-in web server. It reads the raw request, figures out which handler matches the verb and path, and turns the JSON body into Go values. When the work is done, it writes the JSON response and status code back to the client.
• Service — the business logic. It decides what a valid task is, assigns the ID and timestamp, and orchestrates the work. It does not care how tasks are stored.
• Store — where tasks actually live. This is the layer we will swap out partway through the course.

The store layer is the one to watch. We begin with an in-memory store. This means tasks are held in a Go map that only exists while the program runs. If you restart the server, the tasks are gone. It is the simplest possible storage. Using it lets us focus on HTTP and JSON without a database getting in the way. Later, we replace it with PostgreSQL, a real relational database, so tasks survive server restarts.

Here is why this layering is worth the effort. The service and HTTP layers will not need to change when we swap out the store. They talk to the storage layer through a shared definition of what a store must do. Because of this, the in-memory version and the Postgres version are interchangeable. We will lean on this design more than once. It is one of the most useful concepts in the entire course.

The build, step by step

We do not build all of this at once. The course adds one capability at a time, following the order a real project tends to grow.

1. Language foundations. Before building the API, we cover the Go concepts you need to write it. This includes types, structs, slices, maps, interfaces, errors, and a first look at concurrency. We use small, runnable examples with no web server yet.
2. Your first HTTP server. We start the smallest possible server using the standard library and respond to a request. Then we layer on handlers, routing, and JSON until the program can speak HTTP fluently.
3. In-memory CRUD. We build all five endpoints against the in-memory store. The API works end to end, just without a database behind it. This is where the resource shape and status codes discussed above become real code.
4. Tests. Before we add a database, we write tests for what we have built. Testing at this stage is intentional. It builds a good habit, and the test suite is what guarantees that swapping in Postgres later does not break anything.
5. PostgreSQL. We bring in a real database, connect to it from Go, manage its schema, and move the store from memory to SQL. The endpoints stay exactly the same. Only the storage underneath changes.
6. Production concerns. Finally, we make the service shippable. We add request logging, panic recovery, configuration from the environment, structured logging, and graceful shutdown. We finish by creating a small Docker image that packages the whole thing.

You might have noticed we write tests before adding the database. That ordering is deliberate. It is much easier to learn testing against the simple in-memory version. Once those tests exist, they act as a safety net for the bigger database change that follows. Throughout the course, we build the service the way it is done in production, rather than as a toy that just happens to run.

What's Next

That is enough planning. In the next chapter, we will install Go, set up your editor, and run your first program. This ensures your toolchain is completely ready before we write any of the API.