REST API设计用于不是REST[关闭]的操作
我正在为设备管理系统设计REST API。
endpoint：
http://api.example.com/users
http://api.example.com/devices
http://api.example.com/devices/1/send_signal
http://api.example.com/calls
共有1个答案
http://api.example.com/devices/1/send_signal
我知道这不是REST兼容的，我正在寻找一些建议来使它成为正确的方式。
它是REST兼容的。REST并不关心您对资源标识符使用什么拼写。
它会是很好的架构和REST兼容吗？
拼写约定的使用并不会使URI或多或少具有RESTful。参见蒂尔科夫。甚至最好避免使用可预测的标识符，因为这样可以确保使用者读取超媒体表示中提供的标识符，这是重点。
-
模板实体 子文档实体 模板可以有多个子文档如果模板被更新，则可以更新基于该实体的所有或部分子文档。 现在，如果我们想要更新模板，并指示服务器更新所有基于模板的文档，什么是一个好的设计呢？ null 我正在尝试判断其他人在设计REST API时是否也有类似的问题。最近，在使用了很少的API之后，我认为我们可以做得比REST API更好。
-
一个例子可能是： 我的问题是，什么时候将帐户作为客户的子资源公开，而不是作为单独的资源公开，是合适的/更好的？还是两者兼而有之？ 这里有最佳实践吗？
-
所以我非常了解Restful URL设计。然而，对于不是单页应用程序(SPA)的传统网站，浏览器的URL设计如何。 出于本例的目的，让我们假设我们有一个Book数据库。让我们进一步假设我们创建了2个传统的HTML站点。 显示所有书籍的HTML表 用于显示一本书的HTML表单（空白或预先填充了书的详细信息） 浏览器只能进行GET和POST操作，除非有人使用JavaScript。考虑到上面的URL设计
-
问题内容： 从目前的情况来看，这个问题不适合我们的问答形式。我们希望答案能得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 好。我想使用基于REST的服务。 我想使用python。实际上，我将使用python。 我想使用它的方式是从命令行/ ipython开始，尝试不同的REST
-
REST API上下文中的资源是用某种编程语言编写的应用程序代码。可以轻松映射到HTTP谓词的CRUD操作是Save/Edit/Delete代码。难以映射到HTTP方法的非CRUD操作是在服务器上部署代码、执行代码和取消部署。 我在SO中遇到的共同建议是： 重新构造操作，使其看起来像资源的字段，例如，如果您的操作是激活引擎，则设计URI:,body: 将操作视为子资源，例如不带主体 使用查询参数，