敞开生长之旅！这是我参加「日新计划 2 月更文挑战」的第 18 天，点击查看活动概况

1 一般接口完结步骤

完结api的几个步骤

1， 完结 http 处理程序  implement HTTP Handlers
2， 完结测验集
3， 完结自界说类型
4， 完结 API，如 fka Swagger 
               Documentation  文档
                    collaboration  协作
 整合swagger-ui， Integrating swagger-ui
 为咱们的API生成一个Go客户端 generating a go client
5，完结版别操控 versioning
6 真实案例 github REST API

一个好的接口需求投入大量精力去完结，从命名逻辑到数据处理，到高量的并发连接池处理，这里有他人总结的 restful api 的10条原则. 以备参考

1.1 务实 BE PRACTICAL

假如构建一个 REST API， 应该挑选 承受 和 呼应 JSON 格式数据.

1.2 有条有理 BE METHODICAL

		 GET
		 POST
			 当您宣布 POST 恳求时，服务一般希望您存储一些东西。
			您或许将在数据库中创立一个新行，在某处写一些东西或创立假如你愿意的话，从无到有。

			你可以发送运用多个内容将数据发送到 POST 办法
			类型：multipart/form-data 或 x-www-form-urlen 编码或原始（运用程序/json、文本/纯文本...等）。

			在构建 REST API 时，我会主张客户端将数据作为运用程序/json 发送。
			这样咱们坚持共同并本着 JSON 精力，还可以轻松发送真正杂乱的恳求的 JSON 数据。

			最终POST 操作不安全，由于它们的确改变服务器端的东西，它们是当然不是幂等的，
			由于使两个对同一端点的恳求将导致不同的资源。

		 PUT
			 PUT 恳求是最常见的在更新的上下文中运用事物。
			 它也可以用于创立新记载，但随后想法是客户应该是界说新资源的 ID。

			 所以要让您的日子更轻松只需运用PUT 当你想更新一个资源。 
			 PUT 当然不是安全操作，由于它使服务器端的变化，

			 但是，你会喜爱这个的，这是一个相同有用的操作

		 PATCH

			 补丁恳求旨在用于更新
			再次运用资源，但与 PUT 不同，它应该更新
			只有更改的数据，而 PUT 可以和应该更新整个资源。这不安全也不是幂等的。

		 DELETE

大多数人运用GET，POST 和一些运用 PUT 和 DELETE。

很少做我看到正在运用 PATCH。我主张你运用全部您可以运用的 HTTP 办法，

由于这就是它们的设计目的。

您可以直接将任何 CRUD 操作映射到 POST、GET、PATCH 更新和 DELETE 删去。

我只是希望你不要从前运用 GET 来创立或更新数据。

1.3 语义明晰 BE SEMANTICAL

这或许是你仅有一次听到我推荐某人是语义的。但在这种状况下重要的是正确命名事物。
我经常看到 API 文档很糟糕全部的命名约定。

在我看来，每个优异的 REST APi 都应该易于了解你的普通json。
从端点称号到输入参数一直到 JSON 键。

运用称号而不是动词
运用复数而不是奇数

运用名词的原因是由于当您宣布 HTTP 恳求时，正如咱们在上面看到的，你现已在运用动词了。
每个 HTTP 办法（GET、POST、PUT、PATCH）都是英语中的动词。

您应该运用名词的原因是由于当您宣布 HTTP 恳求时，正如咱们在上面看到的，

因而，运用双重动词是没有意义的——不是吗！？

假如您将 API 端点命名为 /getUsers 而且当您大声朗诵时，

您正在宣布 GET 恳求以查看全部用户，这听起来很有趣。得到 /getUsers。没有意义。

我经常看到的另一个常见主题是端点称号运用奇数而不是复数。那个当然不能再错了。
您希望您的 API 端点坚持共同、简略且合乎逻辑。

假如你运用复数然后关于每个 HTTP 办法，您可以运用相同的 URI。

假如你做 GET /users 你列出了全部用户，假如你做 POST /users 你正在创立一个用户。
相同，相同的 URI，不同的 HTTP 办法（动词）。

假如您希望查看单个用户的详细信息，它会变得更酷 – 您恳求 GET /users/:id 来获取信息。
如您所见 – 它依然是相同的起始资源称号，只是更深化。

假如你用过奇数然后 GET /user 意味着您希望取得一个用户而且您需求更多不同其他状况的 URI
复数只是更有意义。 推荐如下办法

    GET /users
    POST /users
    GET /users/23
    PUT /users/23
    DELETE /users/23
    GET /users/23/comments

不推荐如下办法

    GET /user/23
    GET /listAllUsers
    POST /user/create
    PUT /updateUser/23
    GET /userComments/23

关于端点命名的一些额定阐明：
测验运用单个词而不是多个词。假如您真的有必要运用多个单词，请在它们之间设置连字符。
而且为了上帝请在 URI 中运用全部小写字母。

1.4 保证安全 BE SECURE

运用 HTTPs 只是供给了一个安全元素， 它使您的用户免受中间人攻击并加密在客户端和 API 之间的通讯

苹果和谷歌等许多其他大玩家很快就会迫使你运用https 。

最好的部分是现在您可以免费取得 SSL 证书。运用服务像 AWS 和 Route 53、Azure 等价物或名为 Let’s encrypt 的服务。

他们都作业得很好一个 API 没有运用任何办法的授权是过错的。假如你正在构建一个 API，你只需求可以操控谁可以拜访它。

真的不用如此。你可以开端运用可以设置的不记名令牌 bearer tokens

在 2 分钟内。假如您不想，它们乃至不用连接到数据库。

什么时候你预备好了 你可以切换到更杂乱的JWT 或 oAuth 等解决方案。

有许多为什么你应该有某种身份验证解决方案。

     从你这个现实开端可以操控对 API 的拜访以及多少有人可以拜访。
     假如出现问题，就像您的 API 被发送垃圾邮件、被黑客侵略或诸如此类
     您可以简略地封闭露出的密钥。
     您还可以运用 API 密钥来盯梢怎么API被集成了，有人也在做吗
    许多 API 调用，是客户端行为不正常。
    最终，您乃至可以运用 API 调用来搜集有关您的客户端、用户和 API 的统计数据

发送网络上的超级灵敏数据。咱们谈过关于这一点以及运用 SSL 的重要性，以便通讯是加密的。
那将是第一步。第二步是不回来数据这或许是灵敏的，不会在运用程序或网站。

我说的是用户地址、电话号码、SSN 或任何其他办法的身份证明。

假如您不运用它，请不要发送它。假如你正在运用这个，请考虑保证拜访该 API 并获取这些 API 的人
呼应是您的数据的实践人回来。

我知道，这听起来很简略，但实践上人们会做各种张狂的作业。主要是由于他们
在咱们结束之前，我想谈谈 UUID身份证辩论。

我长期以来一直是 ID 的粉丝，由于它们更短更快，但增加了安全性和
在我看来，UUID 的隐私优势更为重要。UUID 更安全。

你依然可以有一个 ID 列 在您的数据库中，它是主动递加的，
除了当您向 API 公开模型时，请测验运用UUID。简短的推荐，但可以为您节约许多的头痛。

我想谈的最终一件事是通用基础设施安全。假如您运用的是 AWS 或 Azure，您有一个优势。
API 网关为您供给额定的安全性在防火墙和 DDoS 攻击检测方面。

选用假如可以的话。任何能让你可以阻止给定的 IP 或用户是你应该一直寻觅的东西。
假如您在传统服务器上运转这里有 Apache 只是两个超级快速的提示关于怎么解救自己一些头疼。

• 关于Apache 服务的安全性

第一个很简略：坚持软件更新。 Apache、PHP、Composer 包、NPM 包…全部。保证您一直运用最新最好的软件。

第二点 默许状况下，Apache 会在每个恳求中发送一个呼应标头，从字面上告知您的潜在攻击者您正在运转哪个版别的 Apache。

标头键称为 Server 和默许值或许相似于：Apache/2.4.1 (Unix)。
你想在这里做的是快速躲藏你的 Apache 版别。

只需翻开：/etc/apache2/conf-enabled/security.conf 并设置对 Prod 的 ServerTokens 值。
之后运转 sudo systemctl restart apache2 ，
你就完结了服务器比昨天更安全。恭喜。

翻开 /etc/apache2/conf-enabled/security.conf 时您可以做的另一件快速的作业是 turn
封闭服务器签名。

只需将其设置为封闭，您就会更加安全。

作为一般规矩，您应该每季度举行一次安全会议，评论诸如怎么
提高安全性，怎么变得更好，怎么坚持安全。

你不想被黑客侵略、DDoSed 或其他什么相似的。信任我。

1.5 版别操控 有条理 BE ORGANIZED

有什么比对 API 进行版别操控更好的办法来坚持有条不紊？
现在我知道你现已读过许屡次并想了一些相似“哦，我的 API 太小，它只一个客户端运用，所以我不会运用版别操控”。

我从前是你们中的一员。但是现在变得更聪明并在您的设备上运用版别API。这是您可以尽早做出的最佳决定。

我总是对版别操控犹豫不决的原因是由于在我看来，从 v1 跳转到 v2 API 等级很少发生。
当我说很少时，我的意思是在科技范畴——每年一次。

知道版别操控对我来说没有意义。但男孩是我错了。是的，大跳跃并不经常发生，
但假如你具有正在运用或开发的渠道或运用程序，您将进行较小的更新，但更频繁。

我是议论有危险的模型、数据类型、结构或流程的每周或每月更新不更新运用程序或其他东西的人。
为此，假如您没有启用版别操控，每次执行 GIT 提交时，您都会汗流浃背。

你不只要保证你的代码不会破坏任何东西或任何人，但您需求知道某个运用程序版别的行为办法。
一点都不好玩 信任我。

只需挑选对您和您的团队最有意义的版别操控方案。
软件世界中常见的版别操控方案是：MAJOR.MINOR.PATCH。

在我看来PATCH 部分有点过多，但假如需求，您可以运用该形式。
我一般做 v1.1然后一直到 v1.9。因而，关于主要版别，您正在更改 API 的中心部分，

例如身份验证、中心模型、流程等。您一般会增加次要版别和补丁版别或删去较小的功能，以某种办法或相似的办法弄乱数据结构。

另一件或许让您感到困惑的作业是怎么实践实施版别操控，由于有许多路。
您可以经过以下办法运用版别操控：URI 途径、恳求标头、查询参数或内容协商

现在每个都有它的长处和缺陷，但我主张运用 URL根据版别操控。

它是最有意义的，也是最容易了解的许多等级。从进行更新到了解运用哪个版别的全部内容
指向正确文档版别的 URL。

REST API 主要根据 URI，我以为咱们应该坚持这种传统并运用根据 URI 的版别操控。
一些比如包括：

            api.domain.com/v1/auth/login
            api.domain.com/v1.2/auth/login
            api.domain.com/v1.4.5/auth/login
            api.domain.com/v2/auth/login

尽早开端运用版别操控，今后您将避免出现问题并可以扩展您的 API

1.6 共同性 可持续性 BE CONSISTENT

您或许听说过这样的说法：“共同性是将均匀转化为卓越的东西”。
这是真的不管你信不信，在日子中以及 API 设计中。优异 API 的品质之一是它的共同性。

首要，我的方针是资源/模型的共同性，然后是其他范畴，如命名、URI、HTTP代码和相似的。
正如咱们现在所知，API 归结为资源。资源可以是用户、文章、书本、产品…任何东西。

每个资源可以有多个属性、目标或数组。
资源是结构化的并根据您在数据库中的数据或其他一些事务逻辑。

坚持资源呼应共同是 API 成功的要害。你不能让你的端点回来完全不同的资源结构。
虽然这听起来很诱人，或许是优化事物的一种办法，但您应该避免这样做。

一种完结您的 API 的移动开发人员将遵从您供给的结构，就像圣经相同。
假如你发送在每个端点时刻都有不同的东西，他或她将度过十分糟糕的一天，没有人想要那样。

所以测验一直发送相同的资源结构。假如您没有数据，则将其作为空值或目标或数组发送。
让咱们谈谈实践，假定咱们有一个“文章”资源，有时该文章或许有定见 – 有时或许没有。

有时加载评论很有意义 – 有时它没有。这很好，但依然测验根据您的结构做出共同的呼应。

当您收到一篇文章时，您也想像这样加载评论：

    {status：true
    message：“article list success”
    articles:[{"title":"","description":"",}{"title":}]
    }

因而，假如客户希望看他们的评论数组依然会得到它，但它只会为空。

这样你就不是更改模型并删去目标/数组。你刚刚保存自己和别人一堆时刻只是坚持共同。

1.7 坚持高雅

假如你正在构建 API，那么作业就会失利。不要紧。这是预期的。
假如你不应该感到伤心您的 API 有过错或问题。

假如您不供给详细信息，您应该感到伤心的是它并保证你的 API 比其他人更聪明。

从顶部开端，我看到开发人员未能运用的最常见的东西之一是 HTTP 状况码。
在假如您不知道 HTTP 关于简直全部可以幻想的场景都有状况码。

你只需求知道运用哪一个并将其发送回客户端。
有超越 50 种不同的 HTTP 呼应状况码它们都有共同的意义，应该在共同的场景中运用。

我不会经过全部这些但咱们将列出最常见的组。咱们有：

信息呼应代码（以 1xx 最初）
重定向呼应代码（以 3xx 最初）
成功呼应代码（以 2xx 最初） 
客户端过错呼应代码（以 4xx 最初）
服务器过错呼应代码（以 5xx 最初）

所以你真的具有你需求的全部状况。
全部正常、未经授权、未找到、内部服务器我是茶壶的过错。

是的，最终一个是实践状况。只是证明制造 HTTPs 的人是终极笑话者！

在任何状况下，这些状况中的每一个都有其意义。这个意思是遍及承受和了解的。
所以来自中国的开发者和来自德国的开发者都会了解，

假如你发送一个状况401（未授权）您的意思是客户端没有发送正确的身份验证详细信息。

由于咱们以 401（未经授权）的状况代码进行呼应，因而每个人都了解这是一个客户端过错
它需求在客户端而不是 API 上修复。

我再次只给你一个比如，但想法是您应该在恰当的状况下运用恰当的 HTTP 状况代码。
运用它们将帮助您的 API遍及可了解、共同和规范。

即便 REST 不是规范，这也是其间之一你应该做的规范作业。

一旦 HTTP 状况代码为咱们作业，咱们需求向咱们供给尽或许多的详细信息当作业不顺利时客户。

咱们有必要做许多作业来完结这一点。首要咱们有必要是可以猜测咱们的 API 或许会怎么失利，其他人或许会做什么和不做什么，谁不会遵守规矩等等……

所以第一步是进行强壮而严厉的数据验证，尤其是在创立内容之前。

在你具有之后您有必要查看数据是否有用！
这意味着查看 ID 是否的确存在，假如值是咱们所希望的，

而且可以将它们存储在数据库中……完结全部这些并以恰当的办法呼应

状况码将使您的 API 易于运用。因而，假定您有一个承受 user_id 的端点
并获取用户配置文件。假如咱们运用猜测或许发生的策略，咱们将执行以下操作：

    01 查看恳求是否有 user_id 参数 - 假如没有呼应 400 Bad Request
    02 查看系统中是否存在给定的 user_id - 假如没有呼应 404 (Not Found)
    03 假如 user_id 回来结果 200 (OK)

如您所见，咱们有多个毛病保险柜，在全部这些保险柜中，咱们都以正确且可了解的呼应代码进行了呼应。

最终，一旦咱们设置了呼应代码而且咱们正在猜测 API 或许会怎么失利，咱们只需需求尽或许的表达。

我知道咱们的开发人员很难做到这一点，但信任我是这样的你能做的最好的作业。
当出现问题时，咱们的 REST API 应该有一个通用的过错呼应模型。

假如咱们有，那么客户端开发人员可以依托它为用户供给更深化的出了什么问题的解说。
假定用户在手机上输入了无效的电子邮件。不知何故被发送到 API，API 当然会触发验证和过错，

并会以 400(Bad Request)。除此之外，API 应该发送一个通用的过错呼应模型，
答应客户端向最终用户显现任何和全部音讯。因而，在这种状况下，您或许会回来一条过错音讯：

“输入的电子邮件地址无效”。客户端可以读取它并将其显现给用户。
咱们需求再次保证您可以涵盖从验证到服务器过错的任何场景。

要做到这一点，咱们最好来有一个通用的过错模型，可以在任何状况下运用。我主张您运用以下内容：

    “title”:”Invalid data”,
    “message”:”The data you entered is not valid”,
    “errors”:[	{“field”: “email”...

过错的 JSON 结构很简略。咱们有一个标题和信息，它供给了一个整体方向发生了什么。

许多时候，开发人员不会挑选向最终用户显现完整的过错详细信息。他们或许会在 iPhone 上运用警报形式来显现咱们的音讯或标题。

但咱们也发送了一个errors 数组，可以容纳带有特定音讯的特定过错。
供给详细的过错信息将帮助您以及其他运用 API 的开发人员了解终究出了什么问题。

乃至假如您没有向最终用户显现它们，您依然可以在宣布恳求后查看它们或许，
假如您运用 Treblle 之类的服务。

所以请记住，请保证您测验猜测尽或许多的问题。
供给大量即便没有人运用这些细节并运用遍及了解的东西，也会详细阐明作业失利的原因HTTP 呼应代码的言语。

1.8 坚持智能

这个比其他的更具哲学性，但在我看来，它是杰出 REST API 的支柱之一。

假如您考虑 API 在现代渠道、服务或运用程序中的作用，咱们可以说
API 是整个操作的大脑。原因是您或许具有的每个客户（iPhone 运用程序，Android 运用程序、网站、物联网设备）将运用相同的 API。

这意味着咱们的 API 是最重要的部分
整个生态系统，咱们的 API 应该可以处理全部作业。高雅地，假如我可以弥补的话。

第一： 维护最重要的财物 数据库
应该做的是维护它最名贵的财物——数据库。

这意味着它应该整理、清除并避免任何不良数据进入数据库。

做到这的办法是制造保证您验证从运用程序发送到客户端的全部内容并回绝任何看起来不正确的内容。

好的。但是当咱们回绝某件事时，咱们也应该向客户供给清晰的理由，
让他们知道为什么发生了什么事，或许在这种状况下没有发生。

智能的 API将 将自行处理杂乱的流程，不依赖客户的帮助
最简略的示例是在您的运用中注册用户。

关于全部应该是一个的客户他们发送数据并取得用户目标的 API 调用。
但是，在后台，API 应该处理任何和全部潜在的物流，

例如：在 MailChimp 时事通讯上注册该用户，将推送令牌存储到 Fire 基地，
向用户发送欢迎电子邮件等等……客户端不应调用多个 API 端点来那些事。

假如咱们将全部内容打包到一个端点中，那么您可以随时轻松更改流程及时，
客户乃至不用意识到这一点。

只要你从他们那里得到你需求的数据 API 一直可以完全操控整个事务逻辑和流程。

当您处理多个渠道或设备，
如 iPhone、Android 手机、计算机、电视等，API 应该可以适应他们。

这意味着 API 应该足够灵活以处理或许不同的输入来自全部客户，
而且依然持续使客户可以完结他们的作业。一个很好的比如是可调整大小的图画。

假如您有一个 API 供给的内容包括您或许不想要的图画将 4000×4000 像素的图画发送到手机，

但也许你会到电视或网站。智能 API 会知道哪个客户端是拜访该端点并回来优化的资源
它自己乃至答应客户要求特定的尺寸。

1.9 精益求精

假如不是快速的和优化，什么是好的 API！？你的 API 不应该是整个生态系统的痛点。

就这么简略。您可以做许多作业来保证供给一个好的 API 应该具备的功能和可扩展性。

• 功能

在数据库层面 做到快速和优化
每逢我听到有人说他们的 API 很慢时 9 到10倍​​它与数据库有关。

要么是糟糕的数据库设计，要么是杂乱的查询，要么是速度慢
基础设施乃至缺乏缓存。您应该一直优化数据库结构、查询、索引以及与数据库交互的全部其他内容。

一旦你处理了接下来的作业重点是保证尽或许供给缓存数据。
缓存数据库查询将有时会从字面上削减 100% 的加载时刻。

因而，假如您有一个 API 端点向用户显现他们的profile 或相似的东西，
我信任它不会每 5 分钟更改一次。聪明点，缓存数据。您的用户调用该 API 的客户会喜爱它。

另一个功能影响要素是您经过 API 发送给客户端的大量数据。
制造保证您的资源和模型只回来客户需求的数据，而不是整个数据包。

假如您正在回来一组项目，也许您不需求完整的模型细节和联系 – 每次。
假如这会加快速度，那就去吧，但总是尽量与回来的模型坚持共同回应。

这意味着假如您没有加载联系，则回来一个空数组，假如您没有加载计数回来 0 等等。
构建超卓的 REST API 时，共同性是要害

• 紧缩
  您可以做的另一件十分简略的作业来削减呼应大小并提高功能是启用紧缩。
  最盛行的一种是 Gzip 紧缩。

在 Apache 上启用默许状况下带有一个名为 mod_deflate 的模块。
启用后，您一般可以看到 Accept-Encoding 的呼应标头设置为 gzip、compress 之类的内容。

即便它默许启用您依然需求将其“运用”到您的 API 呼应中。
为此，咱们有必要在默许值中增加一些规矩apache配置。

所以让咱们像这样翻开配置文件：

   sudo nano /etc/apache2/conf-available/000-default.conf

并增加这个美丽的东西：查看关键

这告知 Apache 对各种 mime 类型运用 Gzip 紧缩，
例如 application/javascript、application/json 等。

一旦咱们保存了这个，咱们只需求经过输入 sudo systemctl restart 来重新启动
Apache/apache2，咱们完结了。您的 API 呼应现在比以前小 50-75%。那有多容易？！

1.10 健壮性 坚持周全

最终一篇我会很短，由于咱们在 REST 上现已过火了（永久不会过期），但我没有想淡化它的重要性。

关于咱们后端开发人员来说，开发 API 的进程是适当美好的孤独。
主要是你，一堆代码和你最喜爱的测验东西。

你或许以为作业完结时您编写最终一行代码并合并到生产分支中。但现实并非如此。
关于许多其他人旅程才刚刚开端。

有许多人只会在你完结你的作业后才开端做他们的作业。
为了他们为了可以做好作业，您需求以多种办法预备 API。

你有必要保证它是作业，它有很好的文档记载，更重要的是你有必要预备好供给集成支撑。

不管你写的文档有多好，总会有问题、疑惑和问题在整合进程中及今后设身处地为他人着想，
努力让他们的作业更轻松。

构建好的 API，遵从咱们的规矩在这里界说，编写超卓的文档并为其他全部人服务。
考虑运用可以帮助您应对构建、交给和运转 API 的许多挑战的东西。

您猜对了，其间一个东西是 Treblle。只需将 Treblle 增加到您的 API，您就会主动生成
具有 OpenAPI 规范支撑的文档。

然后你会得到实时监控和记载，这样你就可以看到其他人正在做什么并更好地帮助他们。
最终，您乃至会取得根据 API 的高质量中心这些相同的规矩。

1.11 示例

• 创立 映射 mapping

    type Action func(out http.ResponseWriter, req * router.Request)
    type Resource map[string]Action
    var resources = map[string]Resource{
      "users": map[string]http.Handler {
        "show": users.Show,
        "list": users.List,
        "listfavorites": users.ListFavorites,
      }
      "sessions": map[string]http.Handler {
        "create": sessions.Create,
        "delete": sessions.Delete,
      }
    }
  

• 界说路由

     r := router.New(router.Configure())
     r.Get("/:resource", ListAction)
     r.Get("/:resource/:id", ShowAction)
     r.Get("/:resource/:id/:child", ListChildAction)
     r.Delete("/:resource/:id", DeleteAction)
  

• 调用恰当的接口 handler

  func ListAction(out http.ResponseWriter, req * router.Request) {
  	resource, exists := resources[req.Param("resource")]
  	if exists == false {
  	// 没有回来值
  	return
  }
  action, exists := resource["list"]
  if exists == false{
  // 没有回来值
  return
      }
      action(out, req)
      }
  

  经过重构 handler函数来 创立另一个
  注册路由途径为：

           "/:resource/:id/:child"
  

url途径为：

            /users/48/favorites

这将查找users资源的动作 listfavorites

	func ListChildAction(out http.ResponseWriter, req *router.Request) {
	  RestDispatch(out, req, "list"+req.Param("child"))
	}
	func RestDispatch(out http.ResponseWriter, req *router.Request, actionName string) {
	  resource, exists := resources[req.Param("resource")]
	  if exists == false {
	    // 没有回来值
	    return
	  }
	  action, exists := resource[actionName]
	  if exists == false {
	    //  没有回来值
	    return
	  }
	  action(out, req)
	}

• 运用反射提高 映射

  type Action func(out http.ResponseWriter, req *router.Request)
  type Resource map[string]Action
  var resources = make(map[string]Resource)
  func Start() {
  	r := router.New(router.Configure())
  	r.Get("/:resource", ListAction)
  	r.Get("/:resource/:id", ShowAction)
  	r.Get("/:resource/:id/:child", ListChildAction)
  	r.Delete("/:resource/:id", DeleteAction)
  	registerActions(users.List, users.Show, users.ListFavorites)
  	registerActions(sessions.Create, sessions.Delete)
  

  }

  非线程安全，主张在init调用
  1 完结一个函数
  2 获取它的全名，比如 github.com/karlseguin/system/users.List
  3 提取 users.List
  4 在users 资源途径 注册 list 动作

  func RegisterAction(actions ...Action) {
  	  for _, action := range actions {
  	    fullName := runtime.FuncForPC(reflect.ValueOf(action).Pointer()).Name()
  	    relevant := strings.ToLower(fullName[strings.LastIndex(fullName, "/")+1:])
  	    parts := strings.Split(relevant, ".")
  	    if len(parts) != 2 {
  	      panic("action " + fullName + " should be in the form of package.name")
  	    }
  	    resourceName, actionName := parts[0], parts[1]
  	    resource, exists := Resources[resourceName]
  	    if exists == false {
  	      resource = make(Resource)
  	      Resources[resourceName] = resource
  	    }
  	    resource[actionName] = action
  	  }
  	}
  

  如此可进一步强制 共同的命名，并削减一些魔术字符串

小结

咱们在设计接口时，需求考虑到了整个团队。

希望我可以简化和解说您或许遇到的一些常见疑问和担忧在构建 REST API 时。
再次，我有必要留意，REST 不是规范，所以没有人可以告知你你在做什么，它是否错了。

但请考虑一下：作为开发人员，咱们每天都在寻觅形式以使咱们的代码更好、更漂亮、
更高效，为什么不对 API 做相同的作业。

假如咱们开端遵从一些形式，咱们都会很享用更健康、更漂亮的生态系统。

“权力越大，责任越大”。

敞开生长之旅！这是我参加「日新计划 2 月更文挑战」的第 18 天，点击查看活动概况