В примере RESTBucks авторы представляют полезную диаграмму состояний, которая описывает действия, которые клиент может выполнять с сервисом.
Откуда такая диаграмма состояния приложения? Ну, это вытекает из требований, конечно.
Поскольку мне нравится определять требования с помощью примеров , давайте посмотрим, как мы можем получить диаграмму состояния приложения из требований стиля BDD .
Пример: диаграмма состояния RESTBucks
Вот три сценария для истории заказа напитка :
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
Scenario: Order a drinkGiven the RESTBucks serviceWhen I create an order for a large, semi milk latte for takeawayThen the order is createdWhen I pay the order using credit card xxx1234Then I receive a receiptAnd the order is paidWhen I wait until the order is readyAnd I take the orderThen the order is completedScenario: Change an orderGiven the RESTBucks serviceWhen I create an order for a large, semi milk latte for takeawayThen the order is createdAnd the size is largeWhen I change the order to a small sizeThen the order is createdAnd the size is smallScenario: Cancel an orderGiven the RESTBucks serviceWhen I create an order for a large, semi milk latte for takeawayThen the order is createdWhen I cancel the orderThen the order is canceled |
Давайте посмотрим на это более подробно, начиная со сценария счастливого пути .
|
1
2
|
Given the RESTBucks serviceWhen I create an order for a large, semi milk latte for takeaway |
Первая строка говорит мне, что есть служба REST, по некоторому заданному URL рекламного щита . Вторая строка говорит мне, что я могу использовать метод POST для этого URI, чтобы создать ресурс Order с заданными свойствами.
|
1
|
Then the order is created |
Это говорит мне, что POST возвращает 201 с расположением созданного ресурса Order.
|
1
|
When I pay the order using credit card xxx1234 |
Это говорит мне, что существует pay действие (отношение ссылки).
|
1
|
Then I receive a receipt |
Это говорит мне, что ответ действия pay содержит представление ресурса Receipt.
|
1
|
And the order is paid |
Это говорит мне, что есть ссылка с ресурса Receipt обратно на ресурс Order. Это также говорит мне, что Заказ теперь находится в paid статусе.
|
1
|
When I wait until the order is ready |
Это говорит мне, что я могу обновить Order, используя GET пока какой-то другой процесс не изменит свое состояние на ready .
|
1
|
And I take the order |
Это говорит мне, что есть действие (ссылка).
|
1
|
Then the order is completed |
Это говорит мне, что Орден сейчас в completed состоянии.
Анализ двух других сценариев аналогичным образом дает нам диаграмму состояний, которая очень похожа на исходную в примере RESTBucks.
Единственное отличие состоит в том, что эта диаграмма содержит дополнительное действие для перехода от получения к заказу. Эта навигация также описана в книге, но не показана на схеме в книге.
Использование методов BDD для разработки RESTful API
Используя сценарии BDD, довольно просто обнаружить диаграмму состояния приложения. Это не должно вызывать удивления, поскольку синтаксис Given/When/Then сценариев BDD — это просто еще один способ описания состояний и переходов между состояниями.
От диаграммы состояния приложения это только маленький шаг к полной модели ресурса. Когда модель ресурсов реализована, вы можете повторно использовать сценарии BDD, чтобы автоматически проверить, соответствует ли реализация требованиям.
В общем, методы BDD могут нам очень помочь при разработке RESTful API.
| Ссылка: | Управляемые поведением API-интерфейсы RESTful от нашего партнера по JCG Ремона Синнема из блога по безопасной разработке программного обеспечения . |




