问与答 URL中使用的动词是否与REST根本不兼容?

neil · 2020-04-27 14:03:44 · 热度: 69

假设我们有一些东西似乎并没有最好地表示为资源(我们要暂停的进程状态,要在服务器上执行的无状态计算等)。

如果在API设计中我们使用process/123/pausecalculations/fibonacci-这与REST根本不兼容吗? 到目前为止,只要使用HATEOAS可以发现这些URL,并且将媒体类型标准化,就可以达到我的理解。

还是我希望在此处回答的消息中采取行动?

注1:
我确实知道可以用名词来改写我的一些例子。 但是我觉得在特定情况下,名词不如动词有效。 因此,我试图了解拥有这些动词是否会立即变得令人讨厌。 如果是的话,那么为什么建议这么严格,以及在这些情况下不遵循我可能会错过哪些好处。

笔记2:
答案“ REST对此没有任何约束”将是一个有效的答案(这意味着该方法是RESTful的)。 回答“这取决于您要问的人”或“这是最佳做法”并不能真正回答问题。 该问题假定REST的概念作为一个定义明确的通用术语存在,两个人可以用来指代同一组约束。 如果假设本身是错误的,并且对REST的正式讨论没有意义,请这样做。

猜你喜欢:
共收到 4 条回复
justin #1 · 2020-04-27 14:03:44

这并不是严格意义上的名词与动词。 关于您是否:

  • 识别资源
  • 通过表示来操纵资源

什么是资源? 因此,Fielding对其进行了定义:

REST中信息的关键抽象是一种资源。 可以命名的任何信息都可以是资源:文档或图像,临时服务(例如“洛杉矶今天的天气”),其他资源的集合,非虚拟对象(例如人)等 。 换句话说,任何可能成为作者超文本引用目标的概念都必须符合资源的定义。 资源是到一组实体的概念性映射,而不是在任何特定时间点对应于该映射的实体。”

现在,您的问题。 您不能只看URL并说:“某某URL是否与REST根本不兼容?” 因为REST系统中的URL并不是很重要。 更为重要的是,URL paused-processescalculations/fibonacci通过上述定义来标识资源。 如果这样做,则不会违反REST约束。 如果不这样做,则违反了REST的统一接口约束。 您的示例使我相信它不适合资源定义,因此会违反此约束。

为了说明该系统中可能存在的资源,您可以通过将其发布到paused-processes资源集合来更改进程的状态。 尽管这可能是处理流程的一种不同寻常的方式,但从根本上讲,它与REST体系结构风格并不兼容。

对于计算,计算本身可能是资源,并且该资源可能看起来像这样:

Request:
GET /calculations/5

Response:
{
  fibonacci: 5,
  prime-number: true,
  square-root: 2.23607
}

再说一次,这是一种有点不寻常的资源概念。 我想稍微更典型的用法如下所示:

Request:
GET /stored-calculations/12381728 (note that URL is a random identifier)

Response:
{
  number: 5,
  fibonacci: 5,
  prime-number: true,
  square-root: 2.23607
}

尽管您可能想存储有关该资源的其他信息,而不是任何人都可以使用计算器进行的纯粹计算...

Response:
{
  number: 5,
  fibonacci: 5,
  prime-number: true,
  square-root: 2.23607,
  last-accessed-date: 2013-10-28T00:00:00Z,
  number-of-retrievals-of-this-resource: 183
}
taven #2 · 2020-04-27 14:03:45

本文有一些不错的提示:[http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api]

从文章引用:

那些不适合CRUD运作的动作呢?

这是事情变得模糊的地方。 有多种方法:

  1. 重组操作以使其看起来像资源的字段。 如果操作不使用参数,则此方法有效。 例如,激活动作可以映射到布尔激活字段,并通过PATCH更新到资源。

  2. 使用RESTful原则将其视为子资源。 例如,GitHub的API允许您使用PUT / gists /:id / star来标记主意,而使用DELETE / gists /:id / star来取消主意。

  3. 有时,您确实无法将操作映射到合理的RESTful结构。 例如,多资源搜索并没有真正   将其应用于特定资源的端点很有意义。 在这   情况下,/ search即使不是名词,也最有意义。   没关系-从API的角度做正确的事   消费者,并确保记录清楚,以免造成混淆。

我个人喜欢建议2。 如果您需要暂停某些内容,您会暂停什么? 如果这是一个具有名称的进程,请尝试以下操作:

/process/{processName}/pause
willem #3 · 2020-04-27 14:03:47

在REST API中使用动词被认为是不好的做法。

在SO和其他地方,有一些关于为什么以及如何避免使用动词的材料。 就是说,有很多使用动词的“ REST” API。

对于您的fibonacci API,我将使资源进程具有POST字段,可以使用GET对其进行修改。

假设fibonacci当前返回:

{
   state: "PAUSED"
}

然后您将fibonacci转换为POST

{
   state: "RUNNING"
}

这使过程更改状态。

在斐波那契的情况下,只需拥有一个名为fibonacci的资源,并在体内使用带有参数(例如前n个斐波那契数字为n)的POST,或者甚至可以在URL中使用GET

jonathon #4 · 2020-04-27 14:03:48

HTTP方法是动词:GET,PUT,POST等,而URL应始终引用名词(动作的接收者)。 这样想:一个句子中的两个动词有意义吗? “获取计算”是胡说八道,其中“获取状态”是良好的,而“获取过程”则更好(“状态”是流程的元数据)。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册