Эта проблема
Скажем, у меня есть классный REST-ресурс /account.
Я могу создавать новые учетные записи
POST /account
{accountName:"matt"}
который может привести к некоторому ответу json, например:
{account:"/account/matt", accountName:"matt", created:"November 5, 2013"}
и я могу найти учетные записи, созданные в диапазоне дат, позвонив:
GET /account?created-range-start="June 01, 2013"&created-range-end="December 25, 2013"
который также может производить что-то вроде:
{accounts: {account:"/account/matt", accountName:"matt", created:"November 5, 2013"}, {...}, ...}
Теперь предположим, что я хочу настроить некоторые образцы данных и написать несколько тестов для ресурса GET /account в пределах определенного диапазона дат создания.
Например хочу как то вставить в систему следующие аккаунты
name=account1, created=January 1, 2010
name=account2, created=January 2, 2010
name=account3, created=December 29, 2010
name=account4, created=December 30, 2010
тогда позвони
GET /account?created-range-start="January 2, 2010"&created=range-end="December 29,2010"
и убедитесь, что возвращаются только учетные записи 2 и 3.
Как мне вставить эти примеры учетных записей, чтобы написать тесты?
Возможные решения
1) Я мог бы использовать инверсию управления и позволить пользователю указывать дату создания новых учетных записей.
POST /account
{account:"matt", created="June 01, 2013"}
Однако, даже если созданное поле было необязательным, мне не нравится такой подход, потому что я не хочу, чтобы мои пользователи могли устанавливать дату создания своей учетной записи. Мне, конечно, нужно иметь возможность сделать это для тестирования, но мне кажется, что эта функциональность как часть общедоступного API неверна. Может быть, я хочу дать кредит в размере 5 долларов любому, кто присоединился к определенному дню. Если они могут указать дату своего создания, пользователи могут играть в систему. Нехорошо.
2) Я мог бы добавить один или несколько ресурсов конфигурации тестирования
PUT /account/creationDateTimestampProvider
{provider="DefaultProvider"}
or
PUT /account/creationDateTimestampProvider
{provider="FixedDateProvider", date="June 01, 2013"}
Этот подход дает мне возможность блокировать эти ресурсы с ограничениями безопасности, чтобы их мог вызывать только мой тестовый контекст, но он также обязательно имеет побочные эффекты в системе, которые могут стать проблемой для управления, особенно если у меня есть куча бэкдоров. ресурсы конфигурации.
3) Я мог бы напрямую взаимодействовать с базой данных, минуя API REST, чтобы установить свои образцы данных.
INSERT INTO ACCOUNTS ...
GET /account?...
Однако это может позволить мне попасть в состояния, в которые использование REST API может не позволить мне попасть, и по мере развития модели базы данных поддержка этих сценариев sql также может быть проблемой.
Итак... как мне проверить свой ресурс GET/account? Есть ли другой способ, о котором я не думаю, более элегантный?
