考虑 REST,将 HTTP 方法映射到 CRUD 操作相对容易:POST 用于创建,GET 用于读取等。但是“即发即弃”操作呢?哪种 HTTP 方法最能代表触发后的操作,例如触发批处理作业(其中没有将响应发送回调用者)?
POST 会浮现在脑海中,但我认为 GET 也是一种合适的方法,因为 99% 的时间您只为这些类型的操作提供一堆参数。你怎么看?
考虑 REST,将 HTTP 方法映射到 CRUD 操作相对容易:POST 用于创建,GET 用于读取等。但是“即发即弃”操作呢?哪种 HTTP 方法最能代表触发后的操作,例如触发批处理作业(其中没有将响应发送回调用者)?
POST 会浮现在脑海中,但我认为 GET 也是一种合适的方法,因为 99% 的时间您只为这些类型的操作提供一堆参数。你怎么看?
POST 会浮现在脑海中,但我认为 GET 是一种更合适的方法,因为 99% 的时间您只为这些类型的操作提供一堆参数。你怎么看?
我认为您使用的参数数量与您使用的动词无关。关键问题是您是否正在更改外部可见状态?
在您的示例中,如果批处理作业不影响任何对象的外部可见状态,那么您可以将其实现为批处理作业。但是,您可以将批处理作业建模为具有关联资源容器的资源。
您可以使用 Post 创建新的 BatchJob 资源并允许用户执行 GET 以查看到目前为止的作业进度。您可以对资源容器执行 GET 以列出所有正在运行的批处理作业,可能调用 DELETE 来杀死一个。
如果您的请求修改数据,则应使用 POST,如果仅读取数据,则应使用 GET。
由于您的请求是“一劳永逸”,我猜它正在修改数据,所以使用 POST。
我认为在一般情况下,我们可能会提供各种有效负载参数,这些参数可能会超出 GET 的可能性,因此 POST 是相当合理的 - 开始工作的操作对我来说并不适合 GET 语义。
想一想,该动作可能不会真正返回响应:
一种)。不,先生,这是一个不可能的要求,我们无法开始您的工作。乙)。明白了,你的工作参考是 93。
如果您在那个级别上担心,也许 HEAD 是您想要的 HTTP 方法;它与 GET 相同,但规定响应体为空。这对我来说听起来很符合你的要求?
我将这个问题从死里复活,以提供不同的观点。
既然 CORS 很流行,那么选择使用GET
还是使用取决于POST
您是否希望知道您的 API URI 的任何人都能够触发批处理作业 ( GET
),或者您是否想要限制请求的来源以防止任何 Joe使用计算机触发作业 ( POST
)。