关于开源项目介绍:初次创建-API-时我会提供的一些重要建议

20次阅读

共计 1971 个字符，预计需要花费 5 分钟才能阅读完成。

当定义 HTTP 办法对于 API 服务，必须应用正确的办法让用户以正确的形式进行查问。一些 HTTPS 办法是:

假如一个内部用户想要通过发送一个 ID 来查问用户表，而您设计的 API 办法应用了 Post 办法。这将限度用户的查问，因为最终用户没有增加或创立数据，并且用户不能以他们应该可能的形式进行查问。

相同，应用 get 办法最好应用一个 ID 作为参数，它应该是这样的:

这将为用户提供应用 ID 进行查问并获取特定数据的选项。

我倡议在定义方法之前理解所有的 HTTP 申请办法，并在被申请时返回正确的 ID。

确保路由十分清晰，这样用户就能够疾速调用我后面展现的 API 服务。

如果你想查问一个苹果的数据库，给 API 命名是没有意义的 ” api/fruits/”

尽管苹果是一种水果，但它不是最终用户想要的。最终用户想要一种特定的水果，所以说出它的名字“API/apple/”。

例如，应用名词这样的词来示意 API 中资源的内容 ” API/ 文具 / 笔 ”。这解释了 API 对信纸数据库中所有笔的查问。

这将代替，例如，“API/ 信纸 /write”。

如果最终用户看到这样的 API，他们可能会感到困惑“api/fruits%20？/ 苹果”。他们不会了解这个 API 是做什么的，或者它是如何查问的，或者它将取得什么信息。

除非须要，否则尽可能防止应用额定的参数。创立 RestFul API 时所需参数的一些示例如下:

申请题目和 cookies: 此参数应用服务器发送到用户 web 浏览器的一小部分数据。
URL 查问字符串: 这些参数元素被插入到您的 URL 中，以帮忙您过滤和组织网站上的内容或跟踪信息。
URL 门路: 这是一个必须的参数，它为最终用户或任何调用 API 的人提供了获取正确信息的办法，例如:”/ 用户 /”, “/users/< 用户 id >/” package/< 包 id > “.
注释查问字符串 / 多局部: 此参数设置问题或 API 的 HTTP 办法，例如邮政–用于发送数据，或放–用于更新 API 中的数据。

那么什么时候须要参数呢？假如内部用户正在对一个 API 服务进行屡次查问，API 会查问其余服务来获取用户想要的数据。

这将升高 API 服务的速度，然而在这种状况下，额定的参数是有帮忙的。

当创立一个微小的微服务并且响应体或对象变得太大时，分页使 API 更容易返回大量信息。

分页是一种在网站或响应对象上将数字内容分成不同页面的办法。

设想一个有 70 个用户的数据库。API 调用获取用户而不是一次发送所有用户的响应并使其变慢。

您能够合成响应，比方返回前三十个用户，随后的三十个用户，以及前面的十个用户。不过，分页响应速度更快。

然而这违反了无状态 API 的属性，即内部用户在他们的终端解决会话相干信息的存储。

当 API 进行外部通信时，响应通常很短。但当它是一个大的响应时，它是一个例外，当它是一个例外时，它就有问题。

当响应超过其限度 (每个响应 10kb 或 15kb) 时，会呈现这种状况。这里的解决方案是将响应合成，而后一点一点地交给另一个服务。

这就像将 TCP(传输控制协议)号分成片段并散发进来，这样服务就不会过载。

它将晓得更多的细节还在前面，它还将有一个完结数据包，如 break 命令，示意当片段行将完结时，协定完结。

以下是这篇文章的一些要点:

防止奇怪的字符，应用代表 API 响应内容的单词。
当响应对象很大时，分页和分段是必不可少的
如果数据库负载很大，应该缓存申请。
如果您有很多负载，缩小您的响应工夫，而不是将残缺的信息传递给用户。只需传入必要或要害的数据。那叫做服务质量降落。它包含提供基本要素，并且依然在不毁坏 API 服务的状况下做出响应。
当设计一个 API 并且你想要一个完满的数据一致性时，缓存你的响应。

最初，并不是人人都须要本人设计 API，如果你对 API 文档、API 测试等方面有需要的话，我举荐大家应用这个 开源的 API 管理工具——Eoapi。

Eoapi 是一个可扩大的 API 工具平台。

Eoapi 汇合根底的 API 治理和测试性能，并且能够通过插件简化你的 API 开发工作，让你能够更快更好地创立 API。

github 地址：
https://github.com/eolinker/e…

Demo 地址：

www.eoapi.io/?utm_source=sf&utm_campaign=xh&utm_content=pd

正文完