I won't be lying, Claude Code was extremely helpful to write those
tests, although it had a lot of issues with properly using in-memory
SQLite (db and integration tests) and with parsing responses
(integration test).
Given the size of the assignment, having everything in the same file was
OK. However, splitting into different files is a good option for better
maintainance once this API grows, and now is a good time to do it before
it gets more complicated.
For now, the config contains:
- database "credentials" (safe to commit, it's just the name of the
sqlite file)
- port on which the HTTP server will listen
This new endpoint was so easy to add, it would have been a shame not to
do it. Besides, it makes sense since the reponse from `POST /items`
provided a `Location` header for the newly created item.
The database that was chosen here is SQLite, because it's dead simple to
setup and more than enough for this project.
Please note that I took some liberty with the assignment. I chose to use
a numeric field for the `id` column of an item. This leverages automatic
creation and incrementation of the id by SQLite itself.
This commit adds a middleware function that checks any POST endpoint is
called with Content-Type: application/json. Returns `HTTP 415
Unsupported Media Type` if this is not the case.
TODO: this commit does not check that the payload is actually
well-formed JSON. If the payload is *not* valid JSON, muutaja will fail,
which will result in an `HTTP 500 Server error`.
This initial version is purposely extremily limited:
* `GET /ahoy` endpoint, just to check the server is alive
* `GET /items` endpoint, always returns the same item
* `POST items` endpoint, checks and print request payload, no
persistance
* calling any other route defaults to a 404
benjamin