Endpoints
| Method | URL Pattern | Handler | Action |
|---|---|---|---|
| GET | /v1/healthcheck | healthCheckHandler | Show application information |
| GET | /v1/movies | listMoviesHandler | Show the details of all movies |
| POST | /v1/movies | createMoviesHandler | Create a new movie |
| GET | /v1/movies/:id | showMovieHandler | Show the details of a specific movie |
| PUT | /v1/movies/:id | editMovieHandler | Edit the details of a specific movie |
| DELETE | /v1/movies/:id | deleteMovieHandler | Delete a specific movie |
Installation
Launch API
go run ./cmd/api
If you want, you can also verify that the command-line flags are working correctly by specifying alternative port and env values when starting the application.
When you do this, you should see the contents of the log message change accordingly. For example :
go run ./cmd/api -port=3030 -env=production
time=2025-10-10T11:08:00.000+02:00 level=INFO msg=
"starting server" addr=:3030 env=production
Test endpoints
curl -i localhost:4000/v1/healthcheck
The -i flag in the command above instructs curl to display the HTTP response headers as well as the response body.
Result
HTTP/1.1 200 OK
Date: Mon, 05 Apr 2021 17:46:14 GMT
Content-Length: 58
Content-Type: text/plain; charset=utf-8
status: available
environment: development
version: 1.0.0
API Versioning
There are two comon approaches to doing this :
- By prefixing all URLs with your API version, like /v1/healthcheck or /v2/healthcheck
- By using custom Accept and Content-Type headers on requests and responses to convey the API version, like Accept: application/vnd.greenlight-v1
From a HTTP semantics point of view, using headers to convey the API version is the 'purer' approach. But from a user-experience point of view, using a URL prefix is arguably better. It makes it possible for developers to see which version of the API is being used at a glance, and it also means that the API can still be explored using a regular web browser (which is hearder if custom headers are required).