WEBVTT 00:00:00.700 --> 00:00:06.972 In this lesson, we will turn an HTTP response into a small, useful list of names. 00:00:07.122 --> 00:00:12.797 Our local API contains three users, but only Ada and Linus are active. 00:00:12.947 --> 00:00:18.344 We will request the data, decode JSON, filter the records, and print the result. 00:00:18.494 --> 00:00:25.806 Everything runs on your own computer, so you can repeat the demonstration without creating an account, 00:00:25.806 --> 00:00:30.377 obtaining a token, or depending on someone else's public API. 00:00:32.530 --> 00:00:38.119 Open a terminal in the downloaded examples directory and start the Python fixture. 00:00:38.269 --> 00:00:41.235 It listens on loopback port ninety three eleven. 00:00:41.385 --> 00:00:45.801 Leave this terminal running and open a second one for HHY. 00:00:45.951 --> 00:00:50.409 The fixture has a users route and a missing route for testing failure. 00:00:50.559 --> 00:00:58.477 Python is just the small test server here; the client that requests and processes its data is written 00:00:58.477 --> 00:00:59.797 entirely in HHY. 00:00:59.947 --> 00:01:02.933 Stop the fixture with Control C when you finish. 00:01:05.080 --> 00:01:09.752 Start by importing HTTP and constructing a GET request. 00:01:09.902 --> 00:01:16.665 The request builder describes the operation; send is the point where the network operation happens. 00:01:16.815 --> 00:01:21.785 Between those steps, add a two second timeout and a small retry policy. 00:01:21.935 --> 00:01:26.202 This order keeps the address, policy, and effect visible together. 00:01:26.352 --> 00:01:32.731 Notice that the returned value is an HTTP response, not the users collection yet. 00:01:32.881 --> 00:01:37.019 We still need to decode its body and select the field we want. 00:01:39.170 --> 00:01:42.007 Response body reads the response as text. 00:01:42.157 --> 00:01:50.349 Parse JSON converts that text into HHY values, and get selects the users field from the outer object. 00:01:50.499 --> 00:01:56.451 These are separate operations because HTTP and JSON are separate formats. 00:01:56.601 --> 00:02:04.151 A successful connection does not guarantee valid JSON, and valid JSON does not guarantee the field 00:02:04.151 --> 00:02:04.623 exists. 00:02:04.773 --> 00:02:09.871 When debugging an unfamiliar API, inspect one stage at a time. 00:02:10.021 --> 00:02:16.272 This makes a schema mismatch much easier to locate than one long unexplained pipeline. 00:02:18.420 --> 00:02:20.553 The users field contains a List. 00:02:20.703 --> 00:02:25.247 Convert it explicitly to a Stream before applying stream operators. 00:02:25.397 --> 00:02:29.621 Where keeps only records whose active field is the Boolean true. 00:02:29.771 --> 00:02:37.573 Map then projects each record to its name, so inactive users and unrelated fields never reach the final 00:02:37.573 --> 00:02:38.006 collection. 00:02:38.156 --> 00:02:44.748 Collect consumes the finite stream, and JSON encoding gives us a machine readable result. 00:02:44.898 --> 00:02:50.658 Run the full client now and compare the two names with the fixture's three input records. 00:02:52.810 --> 00:02:54.751 Now run the missing example. 00:02:54.901 --> 00:03:03.413 The fixture returns a four oh four status, and HHY reports an HTTP status error that our catch block 00:03:03.413 --> 00:03:03.861 prints. 00:03:04.011 --> 00:03:08.854 This is different from a JSON parser error or an unreachable server. 00:03:09.004 --> 00:03:11.884 Keep those distinctions in your troubleshooting. 00:03:12.034 --> 00:03:15.810 Do not assume every failure means the service is offline. 00:03:15.960 --> 00:03:23.118 A wrong route can be fixed in the client, while an unavailable service may require waiting, retrying, or 00:03:23.118 --> 00:03:25.901 presenting a clear failure to the caller. 00:03:28.050 --> 00:03:36.377 A retry policy is useful for temporary failures, but it cannot repair an invalid route or an incompatible 00:03:36.377 --> 00:03:36.839 response. 00:03:36.989 --> 00:03:40.147 Our example uses GET, a read operation. 00:03:40.297 --> 00:03:48.413 Before applying retries to an operation that creates or changes data, understand the API's rules for 00:03:48.413 --> 00:03:49.427 duplicate requests. 00:03:49.577 --> 00:03:57.960 The HHY documentation describes selective retry behavior and does not automatically retry POST by 00:03:57.960 --> 00:03:58.559 default. 00:03:58.709 --> 00:04:06.191 Keep a timeout on every request, and retain the final error when the configured attempts still cannot 00:04:06.191 --> 00:04:07.071 complete successfully. 00:04:09.220 --> 00:04:16.187 For practice, change the projection so the output contains small objects with both name and active 00:04:16.187 --> 00:04:16.623 fields. 00:04:16.773 --> 00:04:23.940 Then change one fixture record from inactive to active, restart the fixture, and predict the new result 00:04:23.940 --> 00:04:25.626 before running the client. 00:04:25.776 --> 00:04:32.112 Keep the filtering and the projection as separate stages so their responsibilities remain clear. 00:04:32.262 --> 00:04:40.399 You now have the foundation for calling real APIs: an explicit request, bounded policy, response 00:04:40.399 --> 00:04:43.654 decoding, and an intentional data transformation. 00:04:43.804 --> 00:04:47.068 Next we will process several requests concurrently.