You've already forked The-API-Book
mirror of
https://github.com/twirl/The-API-Book.git
synced 2025-08-10 21:51:42 +02:00
corrections
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -57,7 +57,7 @@ The asynchronous call pattern is useful for solving other practical tasks as wel
|
||||
* caching operation results and providing links to them (implying that if the client needs to reread the operation result or share it with another client, it might use the task identifier to do so)
|
||||
* ensuring operation idempotency (through introducing the task confirmation step we will actually get the draft-commit system as discussed in the [“Describing Final Interfaces”](#api-design-describing-interfaces) chapter)
|
||||
* naturally improving resilience to peak loads on the service as the new tasks will be queuing up (possibly prioritized) in fact implementing the [“token bucket”](https://en.wikipedia.org/wiki/Token_bucket) technique
|
||||
* organizing interaction in the cases of very long-lasting operations that require more time than reasonable timeouts (which are tens of seconds in the case of network calls) or can take unpredictable time.
|
||||
* organizing interaction in the cases of very long-lasting operations that require more time than typical timeouts (which are tens of seconds in the case of network calls) or can take unpredictable time.
|
||||
|
||||
Also, asynchronous communication is more robust from a future API development point of view: request handling procedures might evolve towards prolonging and extending the asynchronous execution pipelines whereas synchronous handlers must retain reasonable execution times which puts certain restrictions on possible internal architecture.
|
||||
|
||||
|
@@ -2,7 +2,7 @@
|
||||
|
||||
Продолжим рассматривать предыдущий пример. Пусть на старте приложение получает *какое-то* состояние системы, возможно, не самое актуальное. От чего ещё зависит вероятность коллизий и как мы можем её снизить?
|
||||
|
||||
Напомним, что вероятность эта равна она равна отношению периода времени, требуемого для получения актуального состояния к типичному периоду времени, за который пользователь перезапускает приложение и повторяет заказ. Повлиять на знаменатель этой дроби мы практически не можем (если только не будем преднамеренно вносить задержку инициализации API, что мы всё же считаем крайней мерой). Обратимся теперь к числителю.
|
||||
Напомним, что вероятность эта равна отношению периода времени, требуемого для получения актуального состояния к типичному периоду времени, за который пользователь перезапускает приложение и повторяет заказ. Повлиять на знаменатель этой дроби мы практически не можем (если только не будем преднамеренно вносить задержку инициализации API, что мы всё же считаем крайней мерой). Обратимся теперь к числителю.
|
||||
|
||||
Наш сценарий использования, напомним, выглядит так:
|
||||
|
||||
|
Reference in New Issue
Block a user