The endpoint we will build
We are ready to build the endpoint from the introduction, one file at a time. A Get request to slash hello will return a JSON object containing the message Hello, Tinox. We will use a response type, a controller, and the required Main entry class. The final response will come from a compiled program and an independent curl request. Along the way, we will make the dependency setup and the generated startup behavior explicit.

Three types, three files
The source directory contains Greeting, Hello Controller, and Main, each in its own matching filename. Greeting describes the response data. Hello Controller describes the route and produces the value. Main supplies the normal application entry point and imports the controller. Separating the files is not just a presentation preference: Tinox enforces the relationship between a top level type and its filename. We keep imports short when referring to sibling files in this source directory.

Declare matching dependencies
The manifest pins compiler version two point nine point five. It also declares the HTTP server and JSON packages with exact versions. For this course snapshot, we select frozen companion source directories through local overrides. That is an explicit source choice, not a claim that this video downloaded immutable registry archives. The supplied layout keeps those paths relative to the example. Later, the package lesson will compare this local development path with installed registry artifacts.

Select the companion package sources
The override file maps each exact package coordinate to the corresponding companion directory. Running Tinox install resolves that configuration, and Tinox sources reports where the selected code comes from. This makes the origin of the packages visible. Keep the packages directory beside the episodes directory as supplied. If you move it, update the relative paths instead of copying files into an unrelated cache or silently using a different package version.

Describe the JSON response
Greeting imports the JSON module and carries the Json Serializable annotation. Its one field is a String called message. This defines the data shape that the controller will return. We are not constructing a JSON string by hand or escaping quotation marks inside application text. We are describing a typed value, and the serialization path turns that value into the response representation. Keeping the response type small makes the first route easy to inspect.

Declare the route
The controller imports the HTTP server module and our sibling Greeting type. Get chooses the request method. Path selects slash hello. Produces declares application slash JSON. Together, these annotations describe the route's HTTP shape. They do not yet contain the greeting value itself; that belongs in the method body. This separation lets us read the route metadata before reading how the response is produced.

Return an ordinary Greeting
The hello method is an instance method, declared with f n, and its return type is Greeting. Its body returns a Greeting value whose message field is Hello, Tinox. Tinox's route handling serializes that returned object into the JSON response body. The request does not need a custom response writer for this small example. Later, we will use typed response wrappers when we need explicit status codes, headers, or a result that can represent failure.

Add the Main entry class
Main imports Hello Controller and declares the same static main method we already know. It returns zero without manually starting a server. That is intentional: the generated application bootstrap starts the annotated HTTP component and keeps the application alive while that component runs. Importing the controller makes its declarations part of this program. We still provide Main because a normal built application requires the entry class, even when annotation driven components do the ongoing work.

Check the assembled program
Run Tinox install for the selected dependencies, and then Tinox check from the example directory. The captured check result reports three source files with no errors. This checks that our imports, types, annotation usage, and return value fit together. We can also inspect the generated bootstrap with Tinox explain. That inspection describes the configured wiring, while an actual network request will tell us whether the running server responds.

Build for an available port
For this recording, another application was already using the usual port, so we selected a free demonstration port. The Tinox port environment variable is read when building this route bootstrap. Set it on the build command, then start the resulting executable. Changing the environment only after that build does not rewrite the compiled port. The visible number is specific to this recording; choose an available port on your own machine and use the same number in your client request.

Verify the HTTP response
In a second terminal, call the URL with curl and include the response headers. We receive HTTP two hundred O K. The content type identifies JSON with a U T F eight character set, and the body contains the expected message field. These are actual captured results from the example. We also requested an unknown path and received four hundred four Not Found, confirming that a different URL does not accidentally return our greeting.

Exercise: change one thing at a time
Change the greeting message, rebuild, restart the executable, and call the endpoint again. Then try changing the path annotation and compare the old URL with the new one. Predict which request should succeed before you run it. You now have six foundations: a working setup, a program entry, typed values, control flow, reusable methods, and a real web endpoint. The next part of the course will deepen the language before the task board grows into a larger application.
