使用POST作为UPDATE或CREATE时,是否违反了RESTful

Question

鉴于其他部门对我们的REST API的要求,他们POST不仅要使用CREATE,还要使用UPDATE或CREATE.我知道在RESTful API中PUT可以或应该使用它,但由于客户端必须更新用于构建URI的信息,我们不能使用它.它将改变URI并使其PUT不再是幂等的...(旧的URI在第一个之后不存在PUT).
tl; dr我们不能使用PUT

在HTTP/1.1规范中, POST定义为

POST方法用于请求源服务器接受请求中包含的实体作为Request-URI标识的资源的新下级

但是也

POST方法执行的操作可能不会生成可由URI标识的资源.

为了保持RESTful,我会将更新功能解释为旧元素的删除,然后是新元素的创建,这对于POST我会说是可接受的功能.

我们会#201在创建成功时返回,并#200在它只是更新时返回.

---

在我们的API中,"可能"在没有URI的情况下解决正确的元素(例如,用于更新它POST),因为所有构建主要关键部分的URI都在资源体中,因此API知道客户端想要访问哪个元素.

---

例

(这只是行为的一个例子POST.不是资源的数据结构.当然使用PUT是完全正确的/cars/)

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>broken</status>
</car>

回应:#201
然后

POST /cars/ HTTP/1.1
<car>
    <id>7</id>
    <status>fine</status>
</car>

响应:#200
现在GET打开/cars/7将返回以下内容:

<car>
    <id>7</id>
    <status>fine</status>
</car>

Answer 1

"违反RESTfulness"没有严格定义.

一个好的参照度的REST样行为中的接口是理查森成熟度模型,其分离度为REST理想支撑成4层(0是"完全不休息"和3是"完全REST,但几乎没有人确实这个")

在此模型中,在第2级使用RESTful基于HTTP的设计,您的选择只会略有不同.然而,这是许多现实世界项目必须应对的妥协方式.

POST是开放式的,如果你愿意,它可以是幂等的,但HTTP并不要求它.所以你没有打破HTTP,只是错过了使用更密切关联的PUT方法的机会.使用PUT作为API的非幂等部分的相反情况将更成问题.

作为个人观点,我认为如果您在处理不同的HTTP方法和路由时保持自我一致,并将此更改清楚地记录到期望中,那么您可以合理地将您的API称为"RESTful".我认为响应代码拆分200/201就足以编写一个自洽的客户端了.虽然我更愿意在这里看到创建和更新为PUT,但这不会导致我超过片刻的暂停.

您可以考虑按照建议在集合路径(在您的示例中)支持更新或创建POST /cars,以及对项目路径()的更新POST /cars/7."更新或创建"的概念在数据库和ORM框架中很常见,很容易理解.客户端也可以放心地使用后一个仅更新路由,它不会意外地自动创建新记录.