我们有HTTP Web服务，它们是RPC。它们返回表示检索或创建的对象的XML。我想知道“改善”服务的优势（如果有的话）。
我看到的一件事是我们不需要每个资源的表示，我们也不需要支持所有资源上的所有操作（GET，PUT，POST，DELETE）。 基本上我的问题是这个。
说服我，我应该使用restful服务而不是RPC over HTTP，那些宁静的服务应该是什么？
答案 0 :(得分：14)
对于一个关于语义的问题，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资源上的所有谓词，例如，如果您希望只读资源在任何非GET动词上返回405状态码Method Not Allowed。 / p>
你应该重做对REST的RPC调用吗？不，我不这么认为。好处不会超过开发时间。你应该在设置新的Web服务时学习REST吗？是的，我个人确实这么认为，使用REST资源会感觉更自然，并且可以更快地增长。
编辑
为什么我觉得REST胜过XML-RPC / SOAP，因为在开发网站时，您已经将输出的所有必要数据聚合到HTML，您还要为POST主体编写验证代码。为什么要仅因为传输标记更改而更改为其他协议？
这种方式当你设计一个新的网站（语言不可知）时，如果你真的认为URI是资源，你基本上使用你的URI作为方法调用，使用HTTP动词作为方法调用的前缀。
也就是说，带有HTTP标头Accept: application/json;的/ products / 12基本上（虚构）的GET转换为getProducts(12,MimeType.Json)。
这种“方法”必须做几件事
如果出于某种原因，在接下来的4年中，YAML将成为下一个大热潮，并且您的一位消费者希望以这种方式与您交谈，这种MIME类型比常规插入方式容易得多网页服务。
现在，产品12是您最有可能接受HTML MIME类型以显示所述产品的资源，但对于像/product/12/reviews/14/这样的URI，您不需要HTML副本，您只需要您的消费者能够发布到该URL以更新（PUT）/删除（删除）他们自己的评论。
将URI视为资源，而不仅仅是网页的位置，而这些资源又与服务器端方法调用的HTTP请求相结合，导致干净（SEO友好）URL（更重要的是？ ）易于开发。
我确信在任何语言中都有框架会自动将URI映射到方法调用。我不能推荐一个，因为我通常推出自己的。
ASP.NET MVC也遵循相同的原则，但在我看来它不会产生RESTful URI。 ASP.NET MVC默认情况下使URI的动词部分表示，值得注意的是，ASP.NET MVC绝不会强迫你（或任何相关的东西）在你身上。
如果您打算至少选择一个框架，他们应该：
答案 1 :(得分：3)
尝试从您的网址中删除动词：
答案 2 :(得分：0)
不应使用查询字符串以分层，非查询方式访问资源。缓存时通常会忽略查询字符串，这很危险且很慢。