style fix

src/en/clean-copy/01-Introduction/02.md

@@ -1,26 +1,26 @@
 ### The API Definition
 
-Before we start talking about the API design, we need to explicitly define what the API is. Encyclopedia tells us that “API” is an acronym for “Application Program Interface.” This definition is fine, but useless. Much like “Man” definition by Plato: Man stood upright on two legs without feathers. This definition is fine again, but it gives us no understanding of what's so important about a Man. (Actually, not “fine” either. Diogenes of Sinope once brought a plucked chicken, saying “That's Plato's Man.” And Plato had to add “with broad nails” to his definition.)
+Before we start talking about the API design, we need to explicitly define what the API is. Encyclopedia tells us that “API” is an acronym for the “Application Program Interface.” This definition is fine, but useless. Much like the “Man” definition by Plato: Man stood upright on two legs without feathers. This definition is fine again, but it gives us no understanding of what's so important about a Man. (Actually, not “fine” either. Diogenes of Sinope once brought a plucked chicken, saying “That's Plato's Man.” And Plato had to add “with broad nails” to his definition.)
 
-What API *means* apart from the formal definition?
+What the API *means* apart from the formal definition?
 
-You're possibly reading this book using a Web browser. To make the browser display this page correctly, a bunch of stuff must work correctly: parsing the URL according to the specification; DNS service; TLS handshake protocol; transmitting the data over HTTP protocol; HTML document parsing; CSS document parsing; correct HTML+CSS rendering.
+You're possibly reading this book using a Web browser. To make the browser display this page correctly, a bunch of stuff must work correctly: parsing the URL according to the specification, the DNS service, the TLS handshake protocol, transmitting the data over HTTP protocol, HTML document parsing, CSS document parsing, correct HTML+CSS rendering, and so on and so forth.
 
-But those are just the tip of the iceberg. To make the HTTP protocol work you need the entire network stack (comprising 4-5 or even more different level protocols) works correctly. HTML document parsing is being performed according to hundreds of different specifications. Document rendering calls the underlying operating system API, or even directly graphical processor API. And so on: down to modern CISC processor commands being implemented on top of the microcommands API.
+But those are just the tip of the iceberg. To make the HTTP protocol work you need the entire network stack (comprising 4-5 or even more different level protocols) work correctly. HTML document parsing is being performed according to hundreds of different specifications. The document rendering operations call the underlying operating system APIs, or even directly graphical processor APIs. And so on: down to modern CISC processor commands that are implemented on top of the microcommands API.
 
-In other words, hundreds or even thousands of different APIs must work correctly to make basic actions possible, like viewing a webpage. Modern internet technologies simply couldn't exist without these tons of APIs working fine.
+In other words, hundreds or even thousands of different APIs must work correctly to make basic actions possible, like viewing a webpage. Modern Internet technologies simply couldn't exist without these tons of APIs working fine.
 
 **An API is an obligation**. A formal obligation to connect different programmable contexts.
 
-When I'm asked for an example of a well-designed API, I usually show a picture of a Roman aqueduct:
+When I'm asked of an example of a well-designed API, I usually show a picture of a Roman aqueduct:
 
 [![igorelick @ pixabay](/img/pont-du-gard.jpg "The Pont-du-Gard aqueduct. Built in the 1st century AD")](https://pixabay.com/photos/pont-du-gard-france-aqueduct-bridge-3909998/)
 
-  * it interconnects two areas;
+  * it interconnects two areas
   * backwards compatibility being broken not a single time in two thousand years.
 
-What differs between a Roman aqueduct and a good API is that APIs presume a contract to be *programmable*. To connect two areas some *coding* is needed. The goal of this book is to help you in designing APIs which serve their purposes as solidly as a Roman aqueduct does.
+What differs between a Roman aqueduct and a good API is that APIs presume the contract to be *programmable*. To connect two areas *writeing some code* is needed. The goal of this book is to help you in designing APIs which serve their purposes as solidly as a Roman aqueduct does.
 
-An aqueduct also illustrates another problem of the API design: your customers are engineers themselves. You are not supplying water to end-users: suppliers are plugging their pipes into your engineering structure, building their own structures upon it. From one side, you may provide access to the water to many more people through them, not spending your time plugging each individual house into your network. From the other side, you can't control the quality of suppliers' solutions, and you are to be blamed every time there is a water problem caused by their incompetence.
+An aqueduct also illustrates another problem of the API design: your customers are engineers themselves. You are not supplying water to end-users: suppliers are plugging their pipes into your engineering structure, building their own structures upon it. On one hand, you may provide access to the water to many more people through them, not spending your time plugging each individual house into your network. On the other hand, you can't control the quality of suppliers' solutions, and you are to be blamed every time there is a water problem caused by their incompetence.
 
 That's why designing the API implies a larger area of responsibility. **API is a multiplier to both your opportunities and mistakes**.