关于RESTful API的一些问题以及为什么很少实现某些最佳实践的原因

Question

在大多数教程,文档,文章等有关的RESTful我遇到了几个相同点了,但我很少能看到这些"是什么使得它的RESTful"点执行.

例如,我已多次阅读:

• 内容类型

  使用HTTP标头

  Accept: application/json, text/plain 
  

  URL中的扩展名

  Not RESTful, URLs are not the place for Content-Type
  

我从未遇到过我已经看过这个实现的API.我曾经使用的每个API总是要求我在URL的末尾附加XML或JSON.他们做错了吗？

• 版本

  版本媒体类型

  应用/ vnd.something.v1 + JSON

  自定义标题

  X-API-Version:1

  URL中的版本

  / v1/resouce不是RESTful,通过将版本放在您创建单独资源的URL中

如果您需要引入非向后兼容的功能,那么确实创建一个单独的资源是正确的做法吗？

再一次,在我使用的所有API版本中,他们在URL中使用v1,v2(例如google,imgur等)

如果不实现这些要点,我的API不会被视为RESTful吗？

澄清这些要点将非常感激.

Answer 1

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,你会问他们违反了什么约束以及忽略这种约束的实际影响是什么.如果他们无法回答,那么礼貌地忽略它们.