【问题标题】:Why do we have to put api in front of routes?为什么我们必须将 api 放在路由前面?
【发布时间】:2022-01-23 04:09:48
【问题描述】:

我正在学习 express 和 http 方法,但我找不到任何文档。 /api/value 是否仅用于 json 数据,就像仅用于该数据的地址?任何有关它的额外信息将不胜感激。就像它到底做了什么,以及是否有来自 express 的任何文档。或者这是一个在整个框架和互联网中的 url 中使用的全局术语?

例如:

app.get('/api/jackets'(req, res) => {res.send('logic')})

为什么我们需要在夹克之前添加api,它有什么作用?

【问题讨论】:

  • 你不必这样做,这只是一个约定(有很好的理由)。
  • " 如有任何额外信息,我们将不胜感激。" - 额外信息究竟是什么? - 听起来您正在寻求 RESTful Web 服务设计的指导...
  • 只是询问术语本身。
  • “条款本身” - 什么条款?

标签: api express


【解决方案1】:

没必要,只是为了更好的理解

【讨论】:

  • 请扩展并详细说明“它仅用于更好地理解”的意思。
【解决方案2】:

/api 请求不是必须的,但在 API 请求前加上前缀例如:

/api

或者,在某些情况下包括版本号:

/api/v1

允许您将同一网络服务器用于不止一种类型的请求,因为 /api 前缀将每个 API 请求唯一标识为 API 请求,并且可以轻松地将其路由到您处理 API 请求的位置。您可以从由同一 Web 服务器提供服务的浏览器发出纯网页请求。虽然您不必使用这样的前缀,但使用它可以让您在部署和使用服务器时获得最大的灵活性。

类似地,将版本放在前缀中,例如 /api/v1,允许您通过添加新版本名称而不破坏先前的 API 客户端(您支持两个版本在同一时间 - 至少在过渡期内)。

【讨论】:

  • /api/v1-style 版本控制的问题在于,它不容易适应 API 的不同区域与其他区域分开的版本控制,从而有效地迫使您每次都将整个 Web 服务克隆到一个新版本中。是你做出重大改变的时候了。归根结底,在 RESTful 准则下没有简单的版本控制解决方案。
  • @Dai - /api/v1 版本控制有优缺点。我想说你不应该在没有像/api/v1 这样的防御措施的情况下对 API 的一部分进行重大更改。而且,您无需克隆太多内容即可添加新版本。事实上,您可以使用与以前相同的路由器,并为更改的方法提供一个新的方法覆盖。 v2 实现实际上可能只有几行代码。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-17
  • 1970-01-01
  • 1970-01-01
  • 2019-04-17
  • 2021-12-12
  • 2012-06-15
相关资源
最近更新 更多