我应该通过HTTP恢复我的RPC调用吗？

我们有HTTP Web服务,它们是RPC.它们返回表示检索或创建的对象的XML.我想知道"改善"服务的优势(如果有的话).

POST http://www.example.com/createDoodad

获取http://www.example.com/getDoodad?id=13

获取http://www.example.com/getWidget?id1=11&id2=45

POST http://www.example.com/createWidget

POST http://www.example.com/createSprocked

我看到的一件事是我们不需要每个资源的表示,我们也不需要支持所有资源上的所有操作(GET,PUT,POST,DELETE).基本上我的问题是这个.

说服我,我应该使用restful服务而不是RPC over HTTP,那些宁静的服务应该是什么？

首先,它是关于语义的,URI是统一资源指示符.HTTP提供了GET,POST,PUT和DELETE资源的方法.HTTP标头指定我想要接收或发送信息的格式.这一切都可以通过HTTP协议获得.

因此,您可以重复使用用于HTML输出的相同URL来获取XML,JSON的方式就是要使用HTTP.

XML-RPC和SOAP基于调用XSD或WSDL文件描述的方法,而REST基于获取/修改资源.差异很微妙但很明显.URL仅描述资源,而不是SOAP和XML-RPC通常的操作.

REST的好处是你可以利用HTTP动词来修改资源,因为它可以被称为create/new/add等方法调用.有意义的HTTP状态代码而不是不同类型的错误响应,并且能够指定不同的以标准方式在同一资源上格式化.

您也不必接受RESTful资源上的所有动词,例如,如果您希望只读资源只返回Method Not Allowed任何非GET动词的405状态代码.

你应该重做你对REST的RPC调用吗？不,我不这么认为.好处不会超过开发时间.你应该在设置新的Web服务时学习REST吗？是的,我个人确实这么认为,使用REST资源会感觉更自然,并且可以更快地增长.

编辑

为什么我觉得REST胜过XML-RPC/SOAP是因为在开发网站时你已经将输出的所有必要数据聚合到HTML,你也可以为POST主体编写验证代码.为什么要仅因为传输标记更改而更改为其他协议？

这种方式当你设计一个新的网站(语言不可知),如果你真的认为URI是资源,你基本上使用你的URI作为方法调用与HTTP动词前缀方法调用.

也就是说,基于Accept: application/json;(虚构)HTTP头的/ products/12上的GET 转换为getProducts(12,MimeType.Json).

这个'方法'然后必须做几件事

检查我们是否支持JSON作为MIME类型.(验证请求)

验证请求数据

产品12的汇总数据.

格式化为JSON并返回.

如果出于某种原因,在接下来的4年中,YAML将成为下一个大热潮,并且您的一位消费者希望以这种方式与您交谈,这种MIME类型比常规Web服务更容易插入.

现在,产品12是您最有可能接受HTML MIME类型以显示所述产品的资源,但对于像/product/12/reviews/14/您不需要HTML对应的URI ,您只希望您的消费者能够发布到该URL以更新(PUT)/删除(DELETE)自己的评论.

严格地将URI视为资源,而不仅仅是网页的位置,而这些资源又与服务器端的方法调用的HTTP请求相结合,导致干净(SEO友好)URL和(更重要的是？)容易发展.

我确信在任何语言中都有框架会自动将URI映射到方法调用.我不能推荐一个,因为我通常推出自己的.

ASP.NET MVC也遵循相同的原则,但在我看来它不会产生RESTful URI.ASP.NET MVC默认情况下使URI的动词部分表示,值得注意的是,ASP.NET MVC绝不会强迫这个(或任何相关的东西)在你身上.

如果您打算至少选择一个框架,他们应该:

将URI绑定到服务器上的方法

支持对象到JSON/XML等序列化.如果你必须自己写这个,这是一种痛苦,虽然取决于语言,而不是必要的太难.

公开某种类型安全的请求帮助程序,以帮助您确定所请求的内容,而无需手动解析HTTP标头.