我正在寻找更新/刷新老化的应用程序，因为它随着时间的推移变得笨拙。
该应用程序通过药房的配药过程跟踪处方。分配过程包含许多使用条形码扫描仪记录的“活动”。
该应用程序目前是一个用于主 UI 的 asp.net Web 表单应用程序，带有一个 asp.net asmx 服务，提供处理条形码扫描的方法。（条码扫描客户端应用程序是一个 .NET windows 窗体应用程序）
Web 服务（与主 UI 相同的 IIS 网站的 asmx 文件）维护应用程序对象中“实时”处方/用户/活动的集合，以最大限度地减少数据库访问。
我被主要 Web UI 的 MVC 模型所吸引，因为它提供了很好的关注点分离，允许我们为移动设备提供视图等。
我有点不确定的是 Web 服务是否应该转变为 RESTful Web api 服务。这显然会对 MVC 应用程序的设计产生影响。目前的设置让服务完成了很多工作——即我们有一个“进程扫描”的主要方法，它封装了如何处理扫描的所有逻辑，例如：
- 扫描用户条形码 - 服务根据设备 ID 保存此信息（传递给方法的设备 ID）
- 已扫描处方条形码 - 服务检查此设备 ID 是否存在用户条形码，如果为真则存储处方 ID）
- 扫描活动条码 - 服务检查用户/处方是否完整，然后检查用户是否能够记录该活动，如果活动正确，是扫描序列中的正确活动，如果 OK 记录活动，则检查用户之前的活动是否需要完成等
转向 RESTful 实现似乎表明它被拆分为具有以下端点：
获取网络服务/用户/用户 ID
获取网络服务/处方/PRESID
发布网络服务/活动/活动ID
这就是我开始失去情节的地方 - 这似乎让事情变得更加复杂，POST 部分让我感到困惑。给出的所有示例都是非常清晰的案例，您正在更新一个资源（例如订单或客户）。在这种情况下，使用 POST 添加活动可能会对其他活动和处方产生影响。然后我是否应该使调用不那么紧密耦合：即请求应该返回需要更新的活动/处方的 ID，然后我调用额外的 POST / PUT 调用来更新它们？我们不是简单地将逻辑转移到客户端吗......
我是否错过了这里的重点，我是否应该深入研究 web api 并从那里开发其余部分......来自已经这样做的人的任何建议都会很棒！
谢谢