Question

RESTful API应该专注于资源而不是行动。但是，在HTTP上实现RESTful时，由于HTTP方法的表达能力有限，人们会将[action]添加到URL的末尾。

例如为： http://rebilly.github.io/ReDoc/#operation/findPetsByStatus

https://developers.google.com/drive/api/v3/reference/

（DELETE / files / trash和GET / files / generateIds）

对于用户定义ID的API，上述设计会导致冲突。

即。用户创建宠物findPetsByStatus或文件trash或generateIds。

API设计师无法阻止这种情况发生，因为我们无法预见未来。即我们无法保留所有可能用作行动的关键字，因为产品会随着时间的推移而发生变化。

在这种情况下，如何设计API以便我们不会遇到这样的问题？

我想遵循OpenAPI规范，但他们禁止使用/files?action=<someAction>

的API

Answer 1

在这种情况下，如何设计API以便我们不会遇到这样的问题？

改变干;使用用户提供的拼写将标识符限制在端点层次结构的不同部分，而不是担心保留字的操作。

也就是说，您将URI空间视为一堆分区名称空间;你让你的用户在一个名称空间中自定义拼写，你将api操作放在另一个名称空间中。 TA-沓。

/b9d97060-d4db-4b20-a654-22bb0653db69/pets
/08f9a7c2-353b-484d-9e87-56acca4e5a57/pets

请参阅？没有冲突。

如果有人坚持所有宠物端点必须位于/ pets下，那么只需颠倒顺序

即可

/pets/b9d97060-d4db-4b20-a654-22bb0653db69
/pets/08f9a7c2-353b-484d-9e87-56acca4e5a57

另一种可能性是在与您的宠物用品不同的主机上托管宠物管理。

http://search.example.org/pets
http://api.example.org/pets

在拼写参数中，您可以在域中无处不在的语言中找到一些支持。例如，在你谈到消费者注册他们的宠物的环境中，你可以争论

/pets/registry
/pets/forms

将描述已注册宠物的文件与用于与注册宠物做有趣事情的表格分开。

/pets/registry/findPetsByStatus <-- the dog belonging to [Bobby Tables][1]
/pets/forms/findPetsByStatus <-- the documents used to integrate with the pets service

请不要陷入拼写辩论 - 加载/findPetsByStatusForm并提交/findPetsByStatusReport pass the noun test，但它并不是{{1}}。提高API的质量。

如何处理与RESTful API中的操作名称冲突

1 个答案: