RESTful 兼容设计
RESTful 兼容设计
考虑到我需要开发一个REST银行应用程序，允许创建/删除银行账户以及对账户执行以下操作：取款/存款/获取余额。
- 创建一个账户
PUT /Bank/john
在这里我使用PUT而不是POST，因为这个操作是幂等的，并且客户端提供了URL。
- 删除一个账户
DELETE /Bank/john
- 获取余额
GET /Bank/john
- 从账户中取款
POST /Bank/john
action=withdraw&value=10
- 向账户存款
POST /Bank/john
action=credit&value=10
在这里，我使用POST，因为取款/存款明显不是幂等的。这样设计这些操作是否符合REST规范的方式？
我有一种感觉，我正在写一些类似RPC的东西，通过将动词（withdraw | credit）放在action参数中...而我经常读到REST不应该模仿RPC的风格...
RESTful compliant design的问题出现的原因是设计者对于REST架构原则的理解不够自然。他们习惯于以对象为中心的设计方式，而不是以资源为中心。在这种设计方式下，他们将银行账户作为一个资源，但没有将账户中的交易作为独立的资源来考虑。
为了解决这个问题，设计者需要从资源的角度来思考。在这种情况下，账户中的交易应该被视为一个资源。通过使用HTTP动词和路径来表示资源的操作，可以更好地符合REST架构的原则。
例如，存款操作可以表示为：
POST /Bank/Account/John/Transaction
currency=USD&amount=10
取款操作可以表示为：
POST /Bank/Account/John/Transaction
currency=USD&amount=-10
对于这些操作，响应应该包含一个Location头部，指向新创建的交易资源。
为了让API符合RESTful架构的原则，还需要在响应中包含链接和表单。这样可以使得API的使用更加灵活和可扩展。
此外，为了保证存款和取款操作的幂等性，可以通过创建处于“草稿”状态的交易，并要求使用更新（PUT）操作来提交交易。这样可以避免重复执行相同的交易操作。
总之，通过从资源的角度思考，并遵循REST架构的原则，可以设计出符合RESTful的API。这样的设计方式可以使得API更加灵活、可扩展和易于理解。更多细节可以参考amundsen.com/blog/archives/1041。
RESTful compliant design是一种设计原则，旨在创建可扩展、灵活且易于理解的Web服务。然而，有时在实现RESTful设计时会遇到一些问题，下面将讨论这些问题的原因以及解决方法。
问题的原因：
在给出的例子中，有人提出了一个关于如何通过URL来表示账户余额变动的问题。他认为不应该使用像"action=credit&value=10"这样的参数来表示账户余额的变化，而是应该创建更长的URI来表示这个过程。
解决方法：
为了解决这个问题，提出了使用更具描述性的URI来表示账户余额变动的方法。例如，可以使用以下URI来表示不同的操作：
- 创建一个账户：POST /Bank/Accounts/John
- 向账户中存入金额：POST /Bank/John/Money/10
然而，这种解决方法也会违反RESTful设计原则。因为在RESTful设计中，POST方法用于创建资源，而不是用于更新资源。因此，将POST方法用于向账户中存入金额是不符合RESTful设计原则的。
另一个问题是，如果要从账户中提取金额，应该使用什么方法？一种解决方法是使用负值来表示提取金额，但这似乎有点奇怪。
因此，虽然提出的解决方法可以实现所需的功能，但它违背了RESTful设计原则，不符合设计的一致性和规范性。
为了解决这个问题，可以使用以下方法：
- 使用PUT方法来表示更新资源，包括存入和提取金额。例如，以下URI可以用于更新账户余额：
- 存入金额：PUT /Bank/Accounts/John/Deposit/10
- 提取金额：PUT /Bank/Accounts/John/Withdraw/10
通过使用PUT方法来表示账户余额的存取，可以确保符合RESTful设计原则，同时也提高了可读性和可理解性。
在实现RESTful设计时，遵循一致性和规范性是非常重要的。当遇到像上述例子中提到的问题时，应该寻找符合RESTful设计原则的解决方法。在这种情况下，使用PUT方法来表示账户余额的存取是一种更好的解决方法。这样可以确保设计的一致性和规范性，并提高可读性和可理解性。