鉴于RESTful Web服务都基于"一切都表示为资源并且可以通过地址(URI)访问"的神圣理念,这对CRUD应用程序有意义(所有示例都是关于列表/创建/更新/删除实体).但是,其他业务逻辑如何创建一个与CRUD操作无关的简单计算器RESTful服务呢?什么是这样的REST服务的好设计?
其次,如果SOAP的逻辑已经完全有意义,那么使用REST而不是SOAP的真正优势是什么?
HTTP POST不一定必须创建持久资源.在RFC 2616第9.5节中,我们发现:
POST方法执行的操作可能不会生成可由URI标识的资源.在这种情况下,200(OK)或204(No Content)是适当的响应状态,具体取决于响应是否包括描述结果的实体.
这意味着我们可以考虑"创建计算",而不必将计算结果保留在它自己的URL上.您的API可能如下所示:
Request: POST /calculations Content-Type: text/plain 3 + 3 / 12 ^ ( 3 * PI) Response: 200 OK Content-Type: text/plain 3.005454
这样做的好处是,您不会通过URL传递"内容",当您尝试通过URL长度有限的客户端或代理提交长计算时,该内容将会中断.您还可以为请求和响应提供不同的表示形式.
计算机服务很容易以RESTful方式建模."CRUD"中的"R"代表"读",并且没有理由"读"也不能表示"计算".因此,可以通过GET访问简单的反向波兰计算器服务:
GET https://calc.com/rpnCalc?3&4&%2B 7
上面的URI方案只是向GET请求添加了三个参数:
3 4 + (URL-encoded as %2B)
这是一个幂等,安全和可缓存的请求.如果这是一个非常复杂的数学查询,花了很多分钟来计算我可以将这些查询路由到开箱即用的HTTP代理,并使用它来立即返回任何预先计算的值,如果重复查询相同的URI.
根据您需要执行的计算类型,您还可以将非常复杂的查询POST到Calculator资源(将查询作为请求主体传递),并且服务器可能会将URI返回到"result"资源,您可以然后GET检索结果,甚至通过它们分页.
其次,如果SOAP的逻辑已经完全有意义,那么使用REST而不是SOAP的真正优势是什么?
我可以使用像curl这样的命令行工具来访问上面的计算器服务,而无需构建复杂的SOAP.我可以在几秒钟内编写对它的调用,而无需使用任何第三方XML库或SOAP工具包.我可以使用HTTP代理等商品工具来缓存结果并提高性能.我不必担心SOAP互操作性或检查WS-I兼容性.如果我正确使用超链接,那么我可以在不影响现有客户端或让他们甚至重新编译的情况下改进和改进我的服务.没有WSDL版本,也没有我必须维护多年的脆弱合同.客户端已经知道GET/PUT/POST/DELETE做了什么,我没有必要重新定义或重新记录它们的语义.决定使用JSON而不是XML的API客户端可以使用HTTP的内置内容协商功能来获取它.我能做到绝对零的这些事情与SOAP和Web服务.
嘿,如果SOAP符合您的需求,那么就可以了.使用REST有很多好处,但它们可能不适合您的情况.至少,了解REST可以为您提供像这样的好书,然后在获得完整故事之后再想一想.