服务器应允许将Web服务分类为RESTful的最小HTTP动词集是什么？

如果托管人不允许PUT和DELETE，该怎么办？

这真的很重要吗，我可以仅使用GET和POST过得幸福吗？

更新：感谢大家的回答，由于与Bill Venners和Elliotte Rusty Harold的访谈有关，Roger的回答可能是最好的。我现在明白了。

解决方案

回答

如果仅使用GET和POST，它仍然是RESTful的。Web服务只能执行仅需要GET或者POST的操作，所以很好。

回答

是的，我们可以不使用PUT和DELETE来生活。

本文告诉我们原因：
http://www.artima.com/lejava/articles/why_put_and_delete.html

尽管对于真正的RESTafrian来说，这可能是种异端，但在现实世界中，我们将尽自己所能来做。尽可能地合理，并尽可能与自己的约定保持一致，但是我们绝对可以在没有P和D的情况下构建一个良好的RESTful系统。

rp

回答

当今的网络浏览器仅处理GETS + POSTS。例如，在Rails中，通过隐藏的表单字段"伪造"了PUTS + DELETES。

除非框架有一些变通办法来"支持" PUTS + DELETES，否则现在就不必担心它们。

回答

我们还可以使用X-Http-Verb-Override：DELETE实例。 HTTP DELETE。这对于无法更改HTTP动词且仅支持GET和POST的Silverlight客户端也很有用。

回答

如果协议的实现被破坏，则REST允许破坏协议约定(因此，我们要做的唯一非标准的事情就是解决实现的破坏部分)。因此，在REST中允许使用其他方法来表示通常不受支持的动词，例如DELETE或者PUT。

编辑：这是来自Fielding的报价，他是创建和定义REST的报价：

A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]