问题
假设我有一个很酷的 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"}
或者
PUT /account/creationDateTimestampProvider
{provider="FixedDateProvider", date="June 01, 2013"}
这种方法使我能够通过安全约束锁定这些资源，以便只有我的测试上下文可以调用它们，但它也必然会对系统产生副作用，这可能会变得难以管理，特别是如果我有一堆后门配置资源。
3）我可以直接与数据库交互，完全绕过 REST api 来设置我的示例数据。
INSERT INTO ACCOUNTS ...
GET /account?...
然而，这可以让我进入使用 REST api 可能不允许我进入的状态，并且随着 db 模型的发展，维护这些 sql 脚本也可能是一种痛苦。
那么...我如何测试我的 GET /account 资源？还有另一种我不认为更优雅的方式吗？