RESTful API 应该专注于资源而不是操作。 但是，当在HTTP上实现RESTful时，由于HTTP方法的表现力有限，人们会在URL的末尾添加[action]。
例如： 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 规范，但他们不允许 API 与/files?action=<someAction>
在这种情况下，如何设计一个 API 才能避免遇到这样的问题？
更改词干;将使用用户提供的拼写将标识符限制为终结点层次结构的不同部分，而不是需要担心保留字的操作。
也就是说，您将 URI 空间视为一堆分区命名空间;您让用户在一个名称空间中自定义拼写，将 api 操作放在另一个名称空间中。 哒。
/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可能会通过名词测试，但它不会提高API的质量。