REST API 与非 RE​​ST API [关闭]

Posted 2023-03-31

【中文标题】REST API 与非 RE​​ST API [关闭]

【英文标题】：REST API vs non-REST API [closed]

【发布时间】：2016-07-05 05:41:32

【问题描述】：

我阅读了有关 REST API 规范的信息。这些是原则：

一切都是资源 每个资源都可以通过唯一标识符进行识别 使用标准 HTTP 方法

现在假设有一个联系方式的表格

id , owner, contact name,contact number, created At

我想设计一个 API 来使用数据。我可以通过以下方式设计api。

用于获取所有者的联系方式

Get /contact/owner/david

或

Get /getContactByOwner?ownerName="david"

用于写入表格

post /contact/owner

 contactDetail JSON in request param

或

 post /addToContact?owner="john"&...

哪种设计是 RESTful？另一个有什么问题？

【问题讨论】：

向更有经验的程序员征求最佳实践和意见有错吗？ *** 仅用于纠正语法错误吗？ @downvoter。

“许多好的问题会根据专家的经验产生一定程度的意见，但这个问题的答案往往几乎完全基于意见，而不是事实、参考资料或特定专业知识。 " 还有重复的：***.com/q/1619302/3001761

在我的问题中，我问哪种设计是宁静的。如果两者都很平静，那么如果有理由支持，这也是一个有效的答案。每种可能性都可以由其他规范的事实和参考资料来支持。我绝不使用模棱两可的语言。 @jonrsharpe。

我从来没有说过它是模棱两可的，只是它是基于意见和重复的。没有“REST 规范”。

Rest 规范是一组不基于意见的规则。一个 api 是否会变得安静。这不是我在问好坏。@jonrsharpe

【参考方案1】：

RESTful 命名约定的经验法则是使用名词作为端点（因为你的动词应该被限制为 get / post / put / delete / 等）。因此，在您的示例中，Get contact/owner/david 和 Post contact/owner 会更可取。但是，如果您真的使用 REST 架构，从技术上讲，您应该使用 HATEOAS（超文本作为应用程序状态引擎）并在 XML 或 html 响应中包含链接，所以如果您使用的是 JSON，它可能更像 REST，而不是成熟的 REST。归根结底，这完全取决于偏好。只需尝试以某种自我记录和直观的方式使用适合应用程序用户需求的任何内容。