怎么称呼不是RESTful的HTTP API？[关闭]

24

您如何称呼基于HTTP的API，该API使用URI命名资源，并使用HTTP动词（PUT，POST，DELETE，GET ...）来操纵这些资源？

根据Roy Fielding的抱怨，它不是REST，因为没有超媒体。

在我的团队内部，每个人都将其称为“ REST API”。我称其为“类似REST”，但它不是描述性的，其含义还很模糊。我对此非常困惑，因为关于REST存在巨大分歧。我不想参加火焰大战，只是使用正确的用语。

— pkalinow
source

6

您在工作中花费了多少时间进行实际编程，并且花费了多少时间来决定使用哪种术语？假设您发布了一款出色的产品，但在某些内部文档中使用了稍微错误的术语。您的客户会关心吗？

— 布兰丁

3

您如何称呼它以及如何称呼它是两件事。

— JeffO 2015年

13

这个问题真的值得在评论中引起人们的怀疑和怀疑吗？希望有一种体面的，被广泛理解的方式来指代一个高级的，经常使用的概念，这似乎并不荒唐。

— Ben Aaronson

6

@Brandin，言语含蓄。在我可以将USB记忆棒挂在脑上并立即下载我的代码之前，我将不得不使用标签和术语来传达我的意思。如果我说“ SOAP HTTP API”，那将意味着与“ REST HTTP API”明显不同。给事物命名是一个难题，也是一个重要的问题。

— Paul Draper

6

下次您提出该主题并获得抵制时，请准备与您的团队一起放弃该主题。我是那种认为我们必须使用正确的术语以减少误解的机会的人。如果您尝试评估他们的词汇/技术选择，许多人不会这样认为，甚至会将其视为对他们智力的攻击，在这种情况下，这不值得争论。如果您的团队中有一个神经质（或更多）的人，并且他们拒绝接受他们实际上没有在进行REST的想法，那么最好是放弃它。

— 拉文斯汀

43

将其称为HTTP API。

它符合HTTP标准，并且没有其他层次（例如SOAP）。

HTTP标准定义了资源，动词，标头，内容协商等。

REST（表示状态传输）是一种架构，其要求恰好符合现有的HTTP标准，但是HTTP只能独立工作。

以我的经验，90％的“ REST HTTP API”应该称自己为“ HTTP API”。

不要为丢掉REST标签而感到羞耻。与微服务和非关系数据库一样，您不必具有RESTful API就可以了。罗伊（Roy）着手创建他可能寿命最长，最向后兼容的网络应用程序体系结构。他做得很好。但并非所有事物都需要40多年的兼容性。

— 保罗·德雷珀
source

6

“以我的经验，90％的“ REST HTTP API”应该称自己为“ HTTP API”。+1

— Artur Gaspar 2015年

我完全同意。在我目前工作的地方，我们在快速的开发周期中使用尖端的应用程序框架构建了最新的客户端-服务器UI。没什么好休息的。我们仅使用POST。它不是新潮，但是可以很好地完成工作。这是我见过的最干净的代码。

— 罗伯特·哈维

19

理查森成熟度模型像这样

到处张贴。单个端点。（肥皂）
到处张贴。多个端点。（资源）
HTTP VERBS。多个端点。
像2一样，返回到资源的链接。（RESTful）

因此，根据该模型，我将其称为符合Richardson 2级或类似标准的Web服务。

http://martinfowler.com/articles/richardsonMaturityModel.html

— 埃斯本·斯科夫·佩德森
source

8

Hypermedia从未真正在类似REST的API中流行，以至于当API实际上实现超媒体导航时，术语RESTful根本不足以将其与任何其他“ RESTful” Web API区分开。REST已经成为一个无所不包的术语，或者任何基于资源的Web API和诸如Hypermedia API之类的新名称都被创造出来，以专注于超媒体概念。

我并不是真的想提倡使用不正确的术语，但是我认为，对REST的一般现代解释只是意味着大多数人使用统一的URL和HTTP动词。这是不正确的，但是任何了解Fieldings定义的人也应该知道很多其他人不知道。另一方面，仅通过观察现有的“ RESTful” API的实现方式来了解REST的人，在提及诸如HATEOAS或按需代码之类的鲜为人知的REST约束时，就不会知道您在说什么。Fielding可能不喜欢它，但我认为回到原始定义已经为时已晚。老实说：如果您第一次听到有人谈论他的REST API，您会立即认为它不包含超媒体，不是吗？

坚持正确的RESTful定义通常只会造成额外的混乱。就像许多术语随着时间的推移改变了其含义，或者群众只是错误地接受了这些术语一样，如果有人知道原始定义，但如果使用更广泛的现代REST解释的人，我将不予纠正，我深表感谢。

_{_{*并为此建立类似于REST的非超媒体API的新术语。无论如何我们应该如何称呼它们？... 休息？}}

— 卡佩克斯
source

1

Github的API有很多超媒体。我不知道那是多么典型。我同意您的看法，“ RESTful”一词已摆脱了Fielding的控制，无法涵盖更多事物。

— 2015年

2

它是通过HTTP的CRUD接口（创建，读取，更新，删除）。

我想不出任何权威来支持这一主张，所以希望您得到更多更好的答案。

— 浮冰
source

4

RESTful也符合该定义。

— Blrfl 2015年

1

@Blrfl AFAICT一些RESTful API可能是它的超集。如果记录不包含超链接，将不符合Fielding的定义。

— 2015年

2

您可以随心所欲地调用它，人们倾向于（几乎出于宗教目的）锁定您不遵循的REST“规范”的任何部分，并以此作为抗议点，这对开发非常不利。就是说，一个简单的事实是，存在（几乎）零个服务来为其API服务实现真正的REST。

在我们的团队中，我们将其命名Stateless API为“开发中”，因为我们要替换的是遗留的有状态和功能性SOAP API（遗留API本身也从未具有一致且有意义的名称，因此我们也不会太在意名称）。

现在，该项目只有一个API，简称为the <project> API。当我们最终替换它时，新的API将简称为the new <project> API。

除非您有太多的API需要将其与其他API区别开，否则给它任何奇特的描述性内部名称几乎是没有意义的（在这种情况下，您可能还应该重命名所有其他API）。

— 瑟夫
source

虽然最初的问题很糟糕，但这个答案是回答问题的坚实尝试

— Michael Shaw 2015年

2

您可以将其称为Web API。这是一个非常宽泛的术语，但可以避免对其他API类型定义的含义一视同仁。与HTTP API等替代方法相比，该术语的技术性和精确性较低，但是与非技术人员交谈时可能会占优势。

伦纳德·理查森（Leonard Richardson）也使用了这个术语（定义了理查森成熟度模型的Richardson成熟度模型已经提到了另一个答案-一个关于API与REST体系结构的接近程度的公认度量）。如果删除“ RESTful Web API ” 的“ RESTful”部分，则将获得此结果。

— 卡佩克斯
source