But with the second kind API it's much worse. The main problem we foresee is an absence of ‘memory’ for actions being executed. Functions and sensors API is totally stateless, which means we don't event understand who called a function being currently executed, when, and which order it is related to.
So we need to introduce two abstraction levels.
* statuses and other high-level execution parameters nomenclature (for example, estimated preparation time or possible execution error) being the same;
-* methods nomenclature (for example, order cancellation method) and their behavior being the same.
-Execution control level, which provides uniform interface to indivisible programs. ‘Uniform interface’ means here that, regardless of a coffee machine's kind, developers may expect:
+Program runtime level. For the first kind API it will provide just a wrapper for existing programs API; for the second kind API the entire ‘runtime’ concept is to be developed from scratch by us.
+What does this mean in practical sense? Developers will still be creating orders, dealing with high-level entities only:
POST /v1/orders
@@ -1101,7 +1104,7 @@ POST /v1/orders/statistics/aggregate
So always specify exactly which standard is applied. Exceptions are possible, if you 100% sure that only one standard for this entity exists in the world, and every person on Earth is totally aware of it.
Bad: "date": "11/12/2020" — there are tons of date formatting standards; you can't even tell which number means the day number and which number means the month.
Better: "iso_date": "2020-11-12".
-Bad: "duration": 5000 — five thousands of what?
+Bad: "duration": 5000 — five thousand of what?
Better:
"duration_ms": 5000
or
diff --git a/docs/API.en.pdf b/docs/API.en.pdf
index ec6bd6a..8732d83 100644
Binary files a/docs/API.en.pdf and b/docs/API.en.pdf differ
diff --git a/docs/API.ru.epub b/docs/API.ru.epub
index 526db76..e8ab776 100644
Binary files a/docs/API.ru.epub and b/docs/API.ru.epub differ
diff --git a/docs/API.ru.pdf b/docs/API.ru.pdf
index 17150c9..5eda691 100644
Binary files a/docs/API.ru.pdf and b/docs/API.ru.pdf differ
diff --git a/src/en/clean-copy/02-Section I. The API Design/03.md b/src/en/clean-copy/02-Section I. The API Design/03.md
index 56dfde6..e2a758f 100644
--- a/src/en/clean-copy/02-Section I. The API Design/03.md
+++ b/src/en/clean-copy/02-Section I. The API Design/03.md
@@ -231,8 +231,9 @@ But with the second kind API it's much worse. The main problem we foresee is an
So we need to introduce two abstraction levels.
1. Execution control level, which provides uniform interface to indivisible programs. ‘Uniform interface’ means here that, regardless of a coffee machine's kind, developers may expect:
- * statuses and other high-level execution parameters nomenclature (for example, estimated preparation time or possible execution error) being the same;
- * methods nomenclature (for example, order cancellation method) and their behavior being the same.
+
+ * statuses and other high-level execution parameters nomenclature (for example, estimated preparation time or possible execution error) being the same;
+ * methods nomenclature (for example, order cancellation method) and their behavior being the same.
2. Program runtime level. For the first kind API it will provide just a wrapper for existing programs API; for the second kind API the entire ‘runtime’ concept is to be developed from scratch by us.
diff --git a/src/en/clean-copy/02-Section I. The API Design/05.md b/src/en/clean-copy/02-Section I. The API Design/05.md
index de1240e..16b2967 100644
--- a/src/en/clean-copy/02-Section I. The API Design/05.md
+++ b/src/en/clean-copy/02-Section I. The API Design/05.md
@@ -65,7 +65,7 @@ So *always* specify exactly which standard is applied. Exceptions are possible,
**Better**: `"iso_date": "2020-11-12"`.
-**Bad**: `"duration": 5000` — five thousands of what?
+**Bad**: `"duration": 5000` — five thousand of what?
**Better**:
`"duration_ms": 5000`