Статьи

RESTful APIs, управляемые поведением

В примере 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 drink
 
Given the RESTBucks service
When I create an order for a large, semi milk latte for takeaway
Then the order is created
When I pay the order using credit card xxx1234
Then I receive a receipt
And the order is paid
When I wait until the order is ready
And I take the order
Then the order is completed
 
Scenario: Change an order
 
Given the RESTBucks service
When I create an order for a large, semi milk latte for takeaway
Then the order is created
And the size is large
When I change the order to a small size
Then the order is created
And the size is small
 
Scenario: Cancel an order
 
Given the RESTBucks service
When I create an order for a large, semi milk latte for takeaway
Then the order is created
When I cancel the order
Then the order is canceled

Давайте посмотрим на это более подробно, начиная со сценария счастливого пути .

1
2
Given the RESTBucks service
When I create an order for a large, semi milk latte for takeaway

Первая строка говорит мне, что есть служба REST, по некоторому заданному URL рекламного щита . Вторая строка говорит мне, что я могу использовать метод POST для этого URI, чтобы создать ресурс Order с заданными свойствами.

BDD-отдых-1

1
Then the order is created

Это говорит мне, что POST возвращает 201 с расположением созданного ресурса Order.

1
When I pay the order using credit card xxx1234

Это говорит мне, что существует pay действие (отношение ссылки).

BDD-отдых-2

1
Then I receive a receipt

Это говорит мне, что ответ действия pay содержит представление ресурса Receipt.

BDD-отдых-3

1
And the order is paid

Это говорит мне, что есть ссылка с ресурса Receipt обратно на ресурс Order. Это также говорит мне, что Заказ теперь находится в paid статусе.

BDD-отдых-4

1
When I wait until the order is ready

Это говорит мне, что я могу обновить Order, используя GET пока какой-то другой процесс не изменит свое состояние на ready .

BDD-отдых-5

1
And I take the order

Это говорит мне, что есть действие (ссылка).

BDD-отдых-6

1
Then the order is completed

Это говорит мне, что Орден сейчас в completed состоянии.

BDD-отдых-7

Анализ двух других сценариев аналогичным образом дает нам диаграмму состояний, которая очень похожа на исходную в примере RESTBucks.

BDD-отдых-8

Единственное отличие состоит в том, что эта диаграмма содержит дополнительное действие для перехода от получения к заказу. Эта навигация также описана в книге, но не показана на схеме в книге.

Использование методов BDD для разработки RESTful API

Используя сценарии BDD, довольно просто обнаружить диаграмму состояния приложения. Это не должно вызывать удивления, поскольку синтаксис Given/When/Then сценариев BDD — это просто еще один способ описания состояний и переходов между состояниями.

От диаграммы состояния приложения это только маленький шаг к полной модели ресурса. Когда модель ресурсов реализована, вы можете повторно использовать сценарии BDD, чтобы автоматически проверить, соответствует ли реализация требованиям.

В общем, методы BDD могут нам очень помочь при разработке RESTful API.