Asp.net mvc 建议将asp web窗体/asmx web服务应用程序移动到MVC/web API

我希望更新/刷新老化的应用程序，因为随着时间的推移，它变得越来越笨重

该应用程序通过药房的配药过程跟踪处方。分配过程包含许多使用条形码扫描仪记录的“活动”

该应用程序目前是一个用于主UI的asp.net web表单应用程序，asp.net asmx服务提供处理条形码扫描的方法。条形码扫描客户端应用程序是一个.NET windows窗体应用程序

web服务是一个asmx文件，它与主UI是同一个IIS网站，在应用程序对象中维护“实时”处方/用户/活动的集合，以最大限度地减少数据库访问

我被主要web UI的MVC模型所吸引，因为它提供了一个很好的关注点分离，允许我们为移动设备等提供视图

我有点不确定的是web服务是否应该转变为RESTfulWebAPI服务。这显然会对MVC应用程序的设计产生影响。目前的设置使服务完成了大量工作，即我们有一种“过程扫描”的主要方法，它将所有逻辑封装在扫描操作中，例如：

-已扫描用户条形码-服务根据传递给方法的设备ID设备ID保存此条形码

-已扫描处方条形码-服务检查此设备ID是否有用户条形码，如果为真，则存储处方ID

-扫描活动条形码-服务检查用户/处方是否完成，然后检查用户是否能够记录该活动，如果该活动正确，则检查扫描序列中的活动是否正确，如果确定，则检查用户是否需要完成上一个活动等

移动到RESTful实现似乎意味着将其拆分为以下端点：

获取webservice/Users/USERID

获取Web服务/处方/PRESID

发布Web服务/活动/活动ID

这就是我开始失去情节的地方——这似乎让事情变得更复杂，而文章的部分让我困惑。给出的所有示例都是很好的清晰案例，其中您正在更新一个资源，例如订单或客户。在这种情况下，添加使用POST的活动可能会对其他活动和处方产生影响。然后我是否应该使调用不那么紧密耦合：即请求应该返回需要更新的活动/处方的ID，然后我调用其他POST/PUT调用来更新它们？我们不是简单地将逻辑转移到客户机上吗

我是否错过了这里的要点，我是否应该深入研究web api，并从中开发其余部分……任何已经这样做的人的建议都将非常好

谢谢