WEBVTT

00:00:00.700 --> 00:00:05.095
Until now, our scripts have consumed data or produced files.

00:00:05.245 --> 00:00:10.834
In this lesson, an HHY program will answer an HTTP request.

00:00:10.984 --> 00:00:18.835
We will create one local route called hello, read a name from the query string, and return a JSON object.

00:00:18.985 --> 00:00:22.953
The response you see is produced by the built in Web Runtime.

00:00:23.103 --> 00:00:29.492
This is the final project in the first course section, and it connects our knowledge of functions and

00:00:29.492 --> 00:00:31.977
data values to a running network service.

00:00:34.130 --> 00:00:37.437
Create app dot HHY and import web.

00:00:37.587 --> 00:00:43.859
This gives us the core application and response builders described in the Web Runtime chapter.

00:00:44.009 --> 00:00:50.622
We are using those directly, so this example does not require installing a separate web framework.

00:00:50.772 --> 00:00:57.704
The whole application is small enough to read at once, but it still has three distinct responsibilities:

00:00:57.704 --> 00:01:04.636
a handler that computes a response, a route that selects the handler, and a listener that accepts

00:01:04.636 --> 00:01:05.044
connections.

00:01:07.190 --> 00:01:11.094
Define a function named hello with one request parameter.

00:01:11.244 --> 00:01:18.028
The request exposes parsed query parameters, so we read name and put it in a small response object.

00:01:18.178 --> 00:01:24.343
Web JSON creates the HTTP response representation from ordinary data.

00:01:24.493 --> 00:01:31.189
Notice the difference from printing JSON in a command line script: a printed line goes to the server's

00:01:31.189 --> 00:01:36.397
terminal, while a returned Web response goes to the client that made the request.

00:01:36.547 --> 00:01:39.790
The handler's job is to return that response.

00:01:41.940 --> 00:01:46.207
Create an application and register a GET route at slash hello.

00:01:46.357 --> 00:01:50.837
The route path determines which incoming requests should reach our function.

00:01:50.987 --> 00:01:58.134
The function name is passed as a value, so the registration step does not call the handler with a made up

00:01:58.134 --> 00:01:58.475
request.

00:01:58.625 --> 00:02:02.102
The runtime invokes it later for a matching request.

00:02:02.252 --> 00:02:09.150
Keep the leading slash in the route and use the same path in your test command; an incorrect URL should

00:02:09.150 --> 00:02:12.599
not be mistaken for a failure to start the server.

00:02:14.750 --> 00:02:18.697
Add the listener with an explicit host, port, and worker count.

00:02:18.847 --> 00:02:22.495
Loopback keeps this tutorial server on your own computer.

00:02:22.645 --> 00:02:29.680
Port ninety three sixteen is separate from the documentation website, so the two applications can run at

00:02:29.680 --> 00:02:30.922
the same time.

00:02:31.072 --> 00:02:33.973
One worker is sufficient for this example.

00:02:34.123 --> 00:02:41.184
The application is now a persistent service: after starting it, the terminal remains occupied while it

00:02:41.184 --> 00:02:42.507
waits for requests.

00:02:42.657 --> 00:02:47.287
That waiting state is expected, rather than a script that forgot to finish.

00:02:49.440 --> 00:02:57.739
Run HHY serve with the application file, then open another terminal and request the local URL with curl.

00:02:57.889 --> 00:03:03.990
Quote the URL so your shell does not interpret the question mark as a filename pattern.

00:03:04.140 --> 00:03:08.321
Inspect the returned JSON and confirm that name is Ada.

00:03:08.471 --> 00:03:15.174
You have now exercised the full path: the listener accepted a connection, the route selected the

00:03:15.174 --> 00:03:22.295
function, the function read query data, and the runtime sent its JSON response back to the client.

00:03:24.450 --> 00:03:30.735
If the request cannot connect, check whether the server is still running and whether the port matches the

00:03:30.735 --> 00:03:31.085
listener.

00:03:31.235 --> 00:03:37.592
If it connects but the path is unknown, investigate route registration and the URL.

00:03:37.742 --> 00:03:41.625
These are different failure layers and deserve different fixes.

00:03:41.775 --> 00:03:48.871
The supplied verifier checks the successful response and a missing route, then terminates only the server

00:03:48.871 --> 00:03:50.201
process it started.

00:03:50.351 --> 00:03:57.483
During manual practice, stop your server with Control C when you finish so a later run can bind the same

00:03:57.483 --> 00:03:57.839
port.

00:03:59.990 --> 00:04:05.665
Change the query name to Grace and predict the response before sending the request.

00:04:05.815 --> 00:04:12.535
Then add a message field to the returned object, restart the server, and verify the new output.

00:04:12.685 --> 00:04:19.234
Keep deployment, authentication, and more elaborate service architecture for a separate lesson.

00:04:19.384 --> 00:04:27.230
You now have the complete first section's toolkit: scripts, streams, files, data conversion, commands,

00:04:27.230 --> 00:04:33.955
HTTP clients, bounded parallelism, event driven work, and a small JSON API.

00:04:34.105 --> 00:04:40.675
Use the downloaded examples as starting points, and keep checking actual results as you adapt them.