改善Web API的5个小步骤

最新推荐文章于 2024-10-09 21:49:38 发布

dfsgwe1231

最新推荐文章于 2024-10-09 21:49:38 发布

阅读量118

点赞数

文章标签： ui 前端 ViewUI

作为Web开发人员，我最喜欢做的事情之一就是设计和构建Single Page Apps。这意味着我经常与Web API紧密合作。我什至亲自设计了Web API，并获得了不同程度的成功。

以“ API优先” 模型构建应用程序有很多优点，并且肯定会越来越流行，因此在着手进行下一个大型构建之前，我想分享一些您可以做的小事情，这些都会改善大幅度地设计您的API。

在我们开始之前，我想提一下， 即使您的API是私有的 ，这些事情仍然很重要。 随着应用程序的开发，私有API会随着时间的流逝而变得公开，此外，良好的API会加速前端客户端的开发，无论它们是SPA，移动应用程序还是脚本。

使用正确的状态码！

HTTP标准包括一组非常全面的状态代码，供服务器将其作为主体的元数据返回。这些代码可以为API的使用者提供一种很好的方式，使他们能够以编程方式找出发生了什么情况，而不必求助于分析易碎的错误消息。

状态代码分为以下几类：

1xx参考（主要用于服务器）
2xx成功！
3xx重定向
4xx客户端错误（呼叫者可以解决的问题）
5xx服务器错误（呼叫者无法解决的问题）

因此，我确定我们都熟悉404 NOT FOUND，但是409 CONFLICT呢？返回这些更具体的代码有助于客户以更适当的方式对错误（或不同类型的成功）采取行动。

哦，为了上帝的缘故，不要为每件事返回200成功，而是依靠体内的信息来解释发生了什么。令人讨厌这使我想到了下一点...

不要在主体中包含元数据

当您的API返回对请求的响应时，它将在响应的主体中发送大多数数据。那是身体的目的。但是，如果客户端请求分页查看数据怎么办？您需要通知客户各种元数据，例如集合中的项目总数。那去哪儿了？

解决此问题的常见方法是返回包装在某种包装器中的数据，如下所示：

{
  total: 100,
  page: 2,
  results: [ ... ]
}

我不喜欢这样，因为它模糊了资源与接收资源的方法之间的界限。那么元数据应该去哪里？在标题中。

HTTP标准允许自定义标头与响应一起发送。最初，建议自定义标头以X开头，如X-Forwarded-By中一样。由于难以将以前的非标准标头集成到标准中，因此该建议被撤回。 X前缀（最初旨在避免冲突）的替代方法是使用应用程序名称对标头命名空间。例如：

BobsBurgers-ItemCount: 200

优先于多个快速请求而不是整体请求

当我们使用API而不是传统的回发模型来消费数据时，我们在加载数据时可以完全控制UI，因此我们能够以零碎的方式向用户显示数据，并且一旦数据可用。因此，您应该偏向于具有快速返回的多个重点端点的设计，而不是每页一个端点。总的加载时间可能最终会更长，但是如果我的用户给我提要摘要的时候，用户在几秒钟之内看不到复杂的电影来计算评分，则没什么关系。它还允许客户端根据用户的操作对请求进行优先级排序。如果我的用户没有向下滚动那么远，我可能根本不需要加载该评级。