Ms. Aydin no longer wants to see the order list only in the office. The technician Mr. Kowalski should be able to check on his tablet what is on today, and later the website of Brandt Building Services is supposed to show invoices. All three need the same thing: the orders, with the same prices, from one place. That place is a web API. It is the facade that lesson M1.4 spoke of: not a proxy in front of the old program, but a shared interface that the Windows program, the Blazor pages, and later the tablets use.
Everything the API needs, you already have. The price rules are in the library from lesson M3.1, access to the database is in the data layer from lesson M3.2, and the protective layer from lesson M3.3 makes sure that the new code does not disturb the old program. The API adds only one thing: an HTTP face. How Minimal APIs, routes, and parameter binding work is covered in K2, module 2.3 (ASP.NET Core), and the design of interfaces in K2, module 2.12 (designing APIs). This lesson shows what is special about the Order Book.
What belongs where
The API is thin. It calculates nothing itself and does not query the database with SQL of its own:
| Task | Lives in | The API |
|---|---|---|
| Prices, rounding, invoice number | Brandt.OrderBook.Logic |
calls the calculator |
| Reading with a filter and pages | Brandt.OrderBook.Data, folder Queries |
calls the query |
| Writing that affects the old program | Brandt.OrderBook.Data, folder ProtectiveLayer |
calls the writer |
| Shape of the requests and responses | Brandt.OrderBook.Contracts (new) |
uses the types |
| HTTP: routes, status codes, error format | Brandt.OrderBook.Api (new) |
is this layer |
The table has a consequence: Whoever changes a price rule later changes the library, and the API, the page, and the Windows program immediately calculate the same way. Whoever, on the other hand, calculates "just quickly" in an endpoint has created the third copy of the rule that lesson M3.1 has just eliminated.