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

当定义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 地址：