如何设计RESTful API来查询有关动词的信息(例如潜在的POST请求)? [英] How to design a RESTful API that queries info about a verb (e.g. a potential POST request)?

查看:330
本文介绍了如何设计RESTful API来查询有关动词的信息(例如潜在的POST请求)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在学习如何设计一个RESTful API,而且我遇到了困境。

I'm learning how to design a RESTful API and I've come across a quandary.

假设我有一个POST端点来执行操作。该操作具有与之相关的特定成本。成本取决于动作的内容,特别是POST的主体。例如,给出这两个请求:

Say I have a POST endpoint to perform an action. The action has a certain cost associated with it. The cost depends on what the action is, particularly, on the body of the POST. For example, given these two requests:

POST /flooblinate
{"intensity": 50, "colorful": true, "blargs": [{"norg": 43}]}

POST /flooblinate
{"intensity": 100, "colorful": false, "blargs": []}

假设第一个花费500,第二个花费740.

Say the first one costs 500 and the second one costs 740.

我想创建一个方法,告诉我发布操作的成本是多少。由于我没有创建或更新任何内容,似乎GET是最合适的动词。但是,使用GET的请求正文应该没有任何意义。这意味着我必须将数据放入查询字符串中,比如通过URL编码将请求主体传递给POST:

I want to create a method which will tell me what the cost of posting the action will be. Since I am not creating or updating anything, it seems that GET is the most appropriate verb. However, a request body with GET should not have any meaning. This means that I'd have to put the data in the query string, say by URL encoding the request body to be passed to the POST:

GET /flooblinate/getCost?body=%7B%22intensity%22%3A+50%2C+%22colorful%22%3A+true%2C+%22blargs%22%3A+%5B%7B%22norg%22%3A+43%7D%5D%7D

这似乎不太理想,因为它有两种数据格式事情。但是以下内容:

This seems less than ideal since it's two data formats for the same thing. But the following:

POST /flooblinate/getCost
{"intensity": 50, "colorful": true, "blargs": [{"norg": 43}]}

这似乎也不太理想它滥用POST动词来查询信息,而不是创建或更新某些内容。

This also seems less than ideal since it's abusing the POST verb to query information, instead of to create or update something.

这里做出的正确选择是什么?有没有第三种选择?有没有办法从根本上重新考虑这个设计,这将无需做出这个选择?

What's the correct choice to make, here? Is there any third alternative? Is there a way to rethink this design fundamentally which will obviate the need to make this choice?

推荐答案

我个人认为不是添加 dryRyn 标志。除非确实需要,否则我会尽量避免使用布尔标志。

Personally I'm not for adding dryRyn flags. I try to avoid boolean flags in general unless they're really required.

我有两个想法可以涵盖这种情况:

I've two ideas to cover this scenario:


  1. 一种是在后端站点引入状态,例如 STARTED 已完成。当提交给定资源操作时,它具有 STARTED 状态和计算成本,可以通过 GET 方法查看。可以使用 PUT PATCH 方法修改此类资源,并在给定方法将其状态更改为<$ c $时提交C> FINISHED 。删除了在给定时间内没有改变状态的资源,它们的状态被更改为其他终端值。

  2. 第二个想法是引入一个名为eg的新端点。 /计算。如果您需要计算给定操作的成本,您只需将相同的有效负载(通过 POST )发送到此端点,然后再给出成本。然后资源发送可以保存在服务器上用于某些已建立的TTL或永久保存。

  1. One is to introduce state on the backend site, e.g. STARTED, FINISHED. When given resource action is submitted it has STARTED state and calculated cost which cam be viewed via GET method. Such resource may be modified with PUT and PATCH methods and is submitted when given method changes its state to FINISHED. Resources that didn't change its state for given amount of time are removed are their state is changed to other terminal value.
  2. Second idea is to introduce a new endpoint called e.g. /calculations. If you need to calculate the cost of given action you just send the same payload (via POST) to this endpoint and in return a cost is given. Then resource send may be kept on server for some established TTL or kept forever.

在给出的所有场景(包括你的场景)中,有一个需要至少提出两个请求。

In all the scenarios given (including yours) there's a need to make at least two requests.

这篇关于如何设计RESTful API来查询有关动词的信息(例如潜在的POST请求)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆