REST API：如何处理处理逻辑

我读了（其中包括）以下关于API设计的博客：https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling。它帮助我更好地理解了很多方面，但我仍然有一个问题：REST API：如何处理处理逻辑

如何处理处理某些数据并直接给出响应的功能。想想，像翻译，计算或丰富的动词。他们应该使用哪个名词，并且应该使用GET，PUT还是POST进行调用？

P.S.如果它应该是GET，如何处理GET请求的最大长度

来源

2016-12-23 Alfons

那么，我可以告诉你，我知道这件事。

GET   // Returns, JUST return 
DELETE  // Delete 
POST   // Send information that will be processed on server 
PUT   // Update a information

该模式适用于laravel框架。将最有趣的是，你在阅读参考链接

编号： https://rafaell-lycan.com/2015/construindo-restful-api-laravel-parte-1/

来源

2016-12-23 10:44:49

你应该用以下步骤开始：

识别系统中的资源（名词）。
他们都应该回应GET。

让我们拿你的翻译例子。你可以决定源语言中的每一个单词都是一种资源。这将使：

http://example.com/translations/en-fr/hello

可能返回：

Content-Type: text/plain 
Content-Language: fr 

bonjour

如果你的过程是长期运行的，你应该创建一个客户端可以张贴到请求队列，并为他们提供另一个（新）资源，他们可以查询该过程是否已完成。

来源

2016-12-24 18:16:08

翻译是一个动词（好的我可以使用翻译），并且在GET中提交的文本的长度会受到限制。长时间运行的进程不是问题，但是为了API正确性（+存储请求的所有逻辑）而进行POST/PUT和GET是过度的，而不是用户友好的。 – Alfons

@Alfons：如果这个假设的翻译服务基本上是一本字典，您不需要存储请求。大约4096个字符（IE6）的GET请求限制绰绰有余。如果它像Gengo那样，那么长文本的翻译是由人提供的服务，那么您需要有一个长期运行的过程资源。你能否详细说明你的实际情况，以便我能提供更详细的建议。此外，我不同意你的建议，API正确性不是用户友好的。由于API的“正确性”（RESTfulness），网络工作得很好。 –

这实际上是关于命名的讨论，而不是功能。它很可能在你的API中处理逻辑，你只需要小心地命名它。

假想的API时间。它有这个资源：/v1/probe/{ID}它响应GET，POST和DELETE。假设我们想要开始探测，然后想要探测器将计算得到的通量变化给予我们观测（完全组成物体）。虽然这不是一件真实的事情，但我们假设这必须在飞行中进行计算。我的一个勇敢的队友决定在GET /v1/1324/calculateflux上进行计算。

如果我们遵循真正的REST-ful做法......糟糕。突然间我们没有处理名词，是吗？如果我们有GET /v1/probe/1324/calculateflux，我们已经破坏了RESTful实践，因为我们现在要求一个动词 - calculateflux。

那么，我们该如何处理呢？您需要重新考虑名称calculateflux。这并不好 - 它没有在探测器上命名资源。 **在这种情况下，/v1/probe/1324/fluxvalue是更好的名称，而/v1/probe/1324/flux也可以。

为什么？

RESTFUL APIs几乎在它们的URI中专门使用名词 - 记住每个URI都需要描述一个特定的事情，你可以获得POST PUT或DELETE等等。 这意味着，任何时候有一个处理值，我们应该给这个资源处理（或计算）的值的名称。这样，我们通过始终保持当前数据（我们可以随时重新计算Flux值）并保持RESTful，并且我们没有改变探测器的状态（我们没有使用GET保存任何值）。

来源

2017-01-04 21:22:09

REST API：如何处理处理逻辑

回答

相关问题