开发者怎样才能写出好的 API？ _生活知道

本文最初发表于STX Next博客网站，经原作者 Sebastian Buczyński 同意由 InfoQ 中文站翻译分享。
现在，每个人都在关注 API 。API 最早开始流行于大约 20 年前， 2000 年， Roy Fielding 在他的博士论文中首次提出了 REST 这个术语。同年，Amazon、Salesforce 和 eBay 向全世界的开发者介绍了他们的 API，永远改变了我们构建软件的方式。
在 REST 之前，Roy Fielding 论文中的原则被称为“HTTP 对象模型”，随后你会明白这为何非常重要。
随着阅读的深入，你还会看到如何确定你的 API 是否成熟，好 API 的主要品质是什么以及为何在构建 API 的时候，要注重适应性。
RESTful 架构基础
REST 代表表述性状态转移。
适用于前端的后端
如果你必须要构建一个 API 来满足一堆不同的客户端的话，那么这可能会非常困难。针对某个客户端所作出的决策可能会影响其他客户端的功能。
按照适用于前端的后端（backend for frontend）理念，如果你有不同的客户端，它们喜欢不同形式的 API ，比如移动应用可能会喜欢使用 GraphQL，那么就单独为它们构建吧。
只有当你的 API 是一层抽象，并且这个抽象层很薄的时候，这种方式才有效。如果它与你的数据库耦合，或者太大，具有太多的逻辑，那么就无法这样做了。
GraphQL 与 RESTful
很多人都在热炒 GraphQL 。它是一项新兴的技术，但是已经有了很多粉丝，以至于有些开发者声称它将取代 REST 。
尽管 GraphQL 比 RESTful 要新的多，但是它们有很多相似之处。GraphQL 最大的不足之处在于它的缓存，它必须要在客户端或应用程序中实现。现在，有内置的实现了缓存功能的客户端库（比如Apollo），但是这仍然要比使用 HTTP 提供的几乎免费的缓存功能要困难。
从技术讲，GraphQL 位于 Richardson 模型的 Level 0 层级，但是它具有良好 API 的特质。我们可能无法同时使用多个 HTTP 的功能，但是 GraphQL 的出现就是解决这一问题的。
GraphQL 的杀手锏就是聚合不同的 API，并将它们作为一个 GraphQL API 暴露出来。
GraphQL 在处理数据抓取不足和数据过量抓取方面有很好的效果，而这些问题是 REST API 很难进行管理的。这两个问题都与性能有关，如果数据抓取不足，那说明你没有高效地使用 API，所以必须要进行大量的调用。如果数据过量抓取的话，那么 API 调用的数据传输会比必要的数据传输更大，这是对带宽的一种浪费。
小结
借助 REST 与 GraphQL 的比较，我们能够总结出一个好的 API 最重要的品质。
好的 API 的特性
【开发者怎样才能写出好的 API？】我们需要一个清晰的数据表述方式：RESTful 以资源的方式提供了表述。我们需要有一种方式显示有哪些可用的操作：RESTful 通过组合资源和 HTTP 动作实现这一点。我们需要有一种方式来确认是否存在错误/异常：HTTP 状态码可以实现这一点，可能还会包含阐述它们的响应信息。最好能够提供 API 发现和导航的功能：在 RESTful 中，HATEOAS 负责实现这一点。有好的文档是非常重要的：在这方面，可执行、自更新的文档可以解决这个问题，这超出了 RESTful 规范的范围。最后，但同样重要的是，优秀的 API 应该具有缓存功能，除非你的特定情况认为它是不必要的。
REST 和 GraphQL 之间最大的区别是它们处理缓存性的方式。当我们使用 REST 方式构建 API 的时候，我们基本上可以免费获得 HTTP 的缓存功能。如果选择 GraphQL 的话，你需要自行负责为客户端或应用程序添加缓存。
4种主流的API架构风格对比-InfoQ
以上就是朝夕生活（www.30zx.com）关于“开发者怎样才能写出好的 API？”的详细内容，希望对大家有所帮助！

开发者怎样才能写出好的 API？

猜你喜欢