REST API真的是RESTful吗？
我是这个游戏的新手，所以我可能会误解事情。 其实，如果有人告诉我我误解了事情，这将是一个好处。 也许这个人会足够体贴，让我看到正确的道路。 但...
REST适用于Web服务的“ 准则 ”或“ 最佳实践 ”之一（http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services）是您在拨打电话时应使用正确的HTTP方法我误解了它）到REST API的。
但是看看网络上的许多API实现，我所看到的是，对它们进行的调用实际上是GET调用，根据它们的URI ，它们将被API解释为属于HTTP动词或方法之一。
因此，例如，查看Twitter（https://dev.twitter.com/rest/public）的REST API文档，该文档原则上只定义了两个动词/方法（GET和POST），实际上已发送所有呼叫作为GET，并基于GET调用中的URI，由API解释并执行。
例：
获取状态/查找 ：https：//api.twitter.com/1.1/statuses/lookup.json
POST状态/更新 （PUT？）：https：//api.twitter.com/1.1/statuses/update.json
在这两种情况下，调用本身都是使用GET进行的，URI的最后部分将其定义为真正的GET或POST。
总而言之，为了成为真正的RESTful，REST API的Web服务的客户端实现不应该使用适当的HTTP动词/方法吗？
我错过了什么？
你错过了很多，但不用担心，大多数人都是。
事实是，互联网上公开可用的极少数所谓的REST API真的是RESTful，主要是因为它们不是超文本驱动的。 REST成为引用任何不是SOAP的HTTP API的流行词，所以不要指望API仅仅因为它是一个REST API就真正成为RESTful。 我建议阅读这个答案。
根据我的经验，大多数API开发人员都不知道REST是什么，并且相信使用HTTP的任何HTTP API并避免URI中的动词是REST。
REST由一组约束来定义。 其中有统一接口，简单来说就是说你不应该改变底层协议的预期行为。 REST没有与任何特定的协议耦合，但是由于与HTTP一起使用很常见，所以它们有时会变得复杂。
HTTP具有定义好的GET，POST，PUT，DELETE，PATCH和HEAD方法的语义，并且POST方法的语义由服务器决定。 理想情况下，REST API应完全按照RFC 7231中的规定来响应除POST之外的其他方法，但正如您注意到的，有许多API称自己为REST，但不这样做。 这种情况发生的原因很多。 有时对正确的语义存在一个简单的误解，或者是为了保持一致性，或者是因为与不支持所有方法的中介向后兼容以及其他许多原因。
因此，除了正确使用HTTP方法之外，还有很多事情要做到真正的RESTful。 如果一个API没有得到正确的结果，它就需要找到另一个流行词，因为它绝对不是REST。
我不能确切地告诉你的问题是什么，但我相信有一些概念可以帮助你。 请允许我详细说明......
许多API在其API中使用有限数量的HTTP“动词”是正确的。 GET / POST是最常见的。 PUT减少，然后所有其他（删除，头部，选项等）与消失概率一起使用。
用于文件上传的Dropbox Core API允许可选的PUT / POST，其原因是“为了与浏览器环境兼容，POST HTTP方法也被识别。”
事实上限制是浏览器。 流行的Web服务器对所有HTTP请求方法都没有问题，甚至可以组成一个。 毕竟，请求方法只是一些关于Web服务器的字符串。
HTML4和HTML5仅允许GET和POST请求表单请求。 如果你希望你的API通过浏览器被使用 - 嘿为什么不，这听起来像是一个有用的东西 - 然后你只限于GET / POST。 有关这方面的有用讨论，请参阅：https://softwareengineering.stackexchange.com/questions/114156/why-are-there-are-no-put-and-delete-methods-on-html-forms
更复杂的事情是REST不是行业标准。 不存在RFC，ISO或其他文件，详细说明“合规”实施必须且不得做什么。 虽然许多人一直在玩与REST相关的概念一段时间，但REST概念是在Roy Fielding的博士研究中“发明的”。 如果你对这样的事情感兴趣，那就是一篇精彩的文章
是的，根据REST，API应该使用正确的动词。 但是，只要文档清晰并且所有GET请求都是幂等的，那么生活就应该继续顺利进行。
（来源：我写了PipeThru.com，它集成了40多个API，包括Dropbox和Twitter）
你是对的。 如果他们想成为“RESTful”，他们的API应该尊重每个HTTP方法的语义。
粗略地说，REST是关于方法信息 （服务器应该做什么）， 范围信息 （服务器应该这样做的地方）以及我几乎忘记提及的超媒体驱动（请确保在谈话时检查@PedroWerneck对这个问题的极好答案关于它多一点，并参考了Fielding关于此事的博客文章）。
您提到的API所做的是在URL中同时提供方法和范围设定信息。 这并不适合RESTful架构，因为它总体而言告诉我们：
第1点说“使用HTTP方法传达方法信息”，第2点说“使用URIs传达作用域信息”。
同样，如果一个API使用GET来使用URI中的特定参数来执行某些操作（而不是获取某些内容），那么它将使用URI来传递方法信息。
现在，别惊慌。 大多数API都只有RESTful-ish（就像flickr的twitter一样），这意味着它们是REST和其他软件之间的一种动物。 这本身并不坏，只是意味着它们不能完全从RESTful体系结构（和HTTP）所提供的好处中受益。
请记住，RESTful不仅仅是时尚问题，它还有其优点，例如状态，可访问性等。 而这些只能通过使用像他们应该使用的HTTP动词完全实现。
关于使用POST而不是PUT ，考虑到它们具有不同的属性（ PUT是幂等的， POST不是），使用POST并不坏，只要它是统一设计的，也就是说，程序员不应该怀疑POST会做什么对于API中的每个URI：它们都应该表现相同。 （因为它已经是统一的，所以PUT不会因此而受到影响）。我谈到了更多关于这一点的内容 - 并引用了Roy Fielding对此的评论 - 在另一个问题中（查看“Wrapping Up”部分）。