您可以说HTTP REST请求是Web的命令行：它调用特定服务并提供有关它如何执行该服务的详细信息。
实际上，许多Web服务调用转换为创建子进程，将其交给一些相应的参数，并将标准输出复制回HTTP客户端。例如，在线进行Microsoft Word到PDF转换的服务可能具有此工作流程。在某些情况下，当命令行实用程序具有自己的有效接口时，定义新的HTTP API似乎是多余的。这里是否定义了任何标准，或任何有助于“自动”使用HTTP REST包装命令行实用程序并协助输入验证详细信息的软件？
答案 0 :(得分：0)
据我所知，没有标准的方法可以做到这一点。这取决于您提供的服务，您需要的参数以及您期望的结果。有一些指南和良好做法来设计 REST API ，但没有与您提到的内容直接相关。
重要的是要记住REST架构使用client-server model并且协议独立。但是，最常见的方法是通过HTTP protocol设计它。
基于HTTP协议的REST API为您的服务提供URI作为uniform interface并使用standard HTTP methods，允许从支持HTTP的多个客户端调用该服务。
在REST API中，您可以提供不同的资源表示，例如JSON或XML，并且客户端可以根据需要请求最合适的表示。 API调用可以按用户限制，也可以使用您的服务付费。
根据定义，REST应用程序是stateless。这意味着从客户端到服务器的每个请求必须包含服务器必须理解的所有信息，不要利用服务器上任何存储的上下文。因此，会话状态完全保留在客户端上。
根据定义REST应该如何定义的人员Roy Thomas Fielding的说法，stateless约束会导致可见性，可靠性的属性，以及可扩展性：
可见性得到改进，因为监控系统不必超出单个请求数据，以确定请求的完整性质。 可靠性得到了改进，因为它简化了从部分故障中恢复的任务。 可伸缩性得到改进，因为不必在请求之间存储状态允许服务器组件快速释放资源，并进一步简化实现，因为服务器不必跨请求管理资源使用。
stateless方法也反映了设计权衡：
缺点是它可能通过增加在一系列请求中发送的重复数据（每个交互开销）来降低网络性能，因为该数据不能在共享上下文中留在服务器上。此外，将应用程序状态放在客户端可以减少服务器对一致应用程序行为的控制，因为应用程序依赖于跨多个客户端版本的语义的正确实现。