在关于RESTful的大多数教程，文档，文章等中，我遇到了一些相同的观点，但我很少看到这些“实现RESTful的原因”。
例如，我已多次阅读：
内容类型
使用HTTP标头
Accept: application/json, text/plain
网址
中的扩展程序Not RESTful, URLs are not the place for Content-Type
我从未遇到过我已经看过这个实现的API。我曾经使用的每个API总是要求我将XML或JSON附加到URL的末尾。他们做错了吗？
版本
版本媒体类型
应用/ vnd.something.v1 + JSON
自定义标题
X-API-Version：1
网址
中的版本/ V1 /种源 不是RESTful，将版本放在您创建单独资源的URL中
如果你需要引入非向后兼容的功能，那么创建一个单独的资源是正确的做法吗？
再一次，在我使用的所有API版本中，他们在URL中使用v1，v2（例如google，imgur等）。
如果不实现这些要点，我的API不会被视为RESTful吗？
澄清这些观点将不胜感激。
答案 0 :(得分：5)
1）使用accept标头或使用格式特定的URL在RESTful系统中都是有效的。你引用的文章是错误的。
2）说v1/resource不是RESTful也是不正确的。您无法查看URI并对其RESTfulness做出结论。如果您尝试逐步改进系统，在URL的根目录添加v1可能不是一件好事。实际上，它声明了一个全新的URL空间并废弃了旧的空间。这非常激烈。 RESTFul系统尝试并对系统进行渐进式和渐进式更改。因此，/resource/v2实际上与该目标更加兼容。
这里出现的不幸现象是，许多正在学习REST的开发人员发现，声称在做REST的绝大多数系统实际上并不符合REST的限制。因此，他们很快就会热情地告诉每个人什么是RESTful，哪些不是RESTful。其中许多人还没有完全理解这些限制因素，最终会制造出不存在的新约束。 “RESTFul URL”谬误是一个经典之作。 “POST必须创建资源”是另一种常见的。
我对任何学习REST的人的指导是，如果有人告诉你某些东西不是RESTful，你会问他们违反了什么约束以及忽略这种约束的实际影响是什么。如果他们不能回答这个问题，那就礼貌地忽略它们。
答案 1 :(得分：1)
REST的真正定义显然是在Roy Fielding在2002年编写的doctoral dissertation中。那些自称为RESTful的API是否遵循Fielding指定的指导原则？答案是不。 REST的定义已被某些人淡化，只是意味着任何不使用SOAP的东西。我不太担心什么是RESTful，更多的是关于什么是好的做法。最好在请求的标头中指定内容类型。对API进行版本化也是一种很好的做法。 API最佳实践信息的良好资源来自Apigee的人，因为他们在这方面有很多经验。在RESTful API Design查看他们的网络研讨会，他们会询问您是实用主义者还是RESTafarian。