如何使这个概念RESTful？

Question

我有一个处理发送短信的控制器，它被设置为默认资源。现在，业务需求已经改变，我们希望为用户提供三种不同的发送消息的方式：

1. 致联系人名单上的所有人
2. 到其联系人列表的分段部分（预定义）
3. 对于可以选择的个人联系人

此外，他们可以通过两种方式发送短信：Premium（通过短信网关）或标准（通过SMTP）。因此，基本上有六种不同的方式来发送消息（三种用于高级消息，三种用于标准消息）。

要求声明上述三个选项需要以“向导式”格式呈现，作为三个单选按钮选项，然后是一个显示相应表单和列表的提交按钮：

• 如果选项1（发送给所有人），则只显示用于发送短信的文本框
• 如果选项2（发送到细分受众群），则会将细分列表列为单选按钮
• 如果选项3（发送到特定）然后显示所有联系人的可搜索/可排序列表，并在其名称旁边显示复选框，并在提交时选择所有选中要发送的人。

我遇到的问题是如何使其符合资源强加的RESTful约定。这些用例中的每一个在技术上只有一个动作（好吧，两个因为它对应于new / create）但是看起来在行动中需要有过多的逻辑，而且相当混乱（切换语句或类似）。

有更好的方法吗？

Answer 1

我会首先考虑“最简单的方法”。处理和设置多种交付方法的不同params看起来像是不能轻易地包含在一对“新”和“创建”操作中的东西。

在不知道所有细节的情况下，我的第一个建议就是实现像"choose_contacts", "send_to_contacts" and "choose_segments", "send_to_segments"这样的操作，这些操作要么为这些用例准备数据并渲染自己的模板，要么处理传入的数据并处理可能的错误。然后，“新”操作将根据所选选项将处理分配到适当的操作，而不再需要“创建”操作（或者您可以重新使用它来发送单个消息）。我敢打赌，发送单个消息（或一组消息）的代码无论如何都在模型中，所以一旦你以合理的方式处理表单数据，你就必须用正确的参数调用它。

这种方法的好处：

1. 稍后会维护您的代码的人更自然地阅读，因为它明确区分了可用的选项;

2. 您可以更灵活地处理输入参数并处理来自不同表单的错误，因为您将知道要呈现哪个错误状态作为响应，而无需从表单中携带其他数据。细分和联系人可能需要不同的处理，不是吗？

3. 如果您使用某种性能管理应用程序（例如NewRelic），您将看到某些传递处理操作之一是否存在任何性能问题，而不是一般的SMSDelivery #create操作;

我有类似的情况“通过上传/搜索联系人邀请/寻找朋友”过程，并且给定的方法对我来说非常好。总体而言，REST是一个很好的约定，但是尝试将大量业务逻辑压缩到CRUD中有时并不完美且容易出错。 YMMV，我建议保持逻辑清晰易读，修改现有约定，如果你对它们感觉不够灵活。