api 获取网络使用情况
免责声明：在纯REST中，API是不透明的，URL应该是对先前请求的响应中作为链接发送的内容。 但是，我不是在讲纯REST，而是在讲更实用的API，其中涉及REST的一些概念以及通用的API最佳实践。
编写API时，它很简单。 您确定明显的资源并以以下终结点结束：
/api.mycompany.com/tweet最终，您的API将必须捕获更复杂的概念，并对无法用简短的单个名词表达的更复杂的资源进行建模。 现实世界中的一些示例包括：
- 通过请求验证器资源（AWS API网关API）启用请求验证
- 通过客户搜索资源（Google客户搜索API）执行客户搜索
- 通过检查运行资源（Github API）对代码运行强大的检查
在英语语法中，实际上是两个以某种方式连接的名词的名词称为复合名词 ，在英语语法中，复合名词遵循以下三种模式之一：
- 一句话：理发，牙膏
- 两个词：雨林，冰淇淋
- 连字：自尊，brother子
在API世界中，可以选择不同的选项，但是为了保持一致性，API只选择一种方法并坚持使用是更好的选择。 那么，首先，从API角度来看，复合名词有哪些选择？
骆驼香烟盒
驼峰式大写是在短语中用大写字母写每个单词的做法。 有两种变体：
- 首字母大写（也称为Pascal的大小写 ）是首字母也是大写的地方，例如： IceCream 。 Pascal的案例在用于命名类（例如Java）的编程语言中很流行。
- 首字母小写是首字母始终小写的地方，例如： iceCream 。 这种方法在用于命名变量的编程语言（ 再次是Java的一个很好的例子 ）中很流行。 人们说骆驼的情况时， 通常是指最初的小写形式。
烤肉串盒
在Kebab案例中，各个单词之间用连字符分隔。 冰淇淋表示为冰淇淋 。 Lisp编程语言在许多URL中使用了这种方法（例如，www.blogger.com中的每个博客文章，例如http://dublintech.blogspot.com/2018/08/oauth-20-authorisation-code- grant.html）。
你们当中的观察者会注意到，有时在技术参考中使用“ 破折号”代替“ 连字符”。 那么，有什么区别呢？ 在英语语法中，连字符是用来将两个单词组合成一个单词的东西，而破折号通常是用来在句子的末尾添加某种风格上的强调的东西，例如：“我在这里可能有一个有趣的观点， 您永远不会知道” 。
在编程中，我们不在乎该术语是连字符还是破折号 。 它们可互换使用，表示同一件事。
kebab案例方法在Web URI中变得很流行，因为搜索引擎知道连字符代表单独的单词，并且可以正确索引URI。 搜索引擎使用的这种约定意味着连字符已成为URI的事实上的标准。
蛇皮套
在这种方法中，下划线用于分隔单词。 冰淇淋变成冰淇淋。 除类名或静态常量外，该方法在Python和Ruby中也可使用。
连接词
在这种方法中，单词只是连接在一起。 没有-，没有_，也没有大写 。 这在开发人员中并不流行，因为它很难阅读。
蜜蜂
我们应该在API中使用camelCase，kebab-case或snake_case吗？ 不幸的是， 菲尔丁先生的论文没有这么详细。 那么人们实际上在做什么呢？ 并且在API的URL和JSON主体之间使用的方法是否一致。 让我们来看看。
AWS
AWS具有用于不同服务的不同API样式。 API Gateway REST API参考显示JSON负载使用驼峰式大小写
但该网址什么也没用，只是：
/restapis/{id}/requestvalidators/{requestvalidatorId}谷歌
惊喜，惊喜Google也有很多API 。 谷歌
自定义搜索API与AWS API Gateway API相似。 URL中的复合名词只是一个单词，JSON主体是驼峰式大小写。
Google Gmail API在请求正文和某些URL中使用了驼峰形式，例如， 转发地址API 。
Google youtube API有时会在网址中使用kebab大小写，例如
yt-analytics，但在其他情况下将使用单个词，例如youtubepartner。 但是，JSON有效负载是驼峰式的情况。
Github
Github API是一个很好的例子，在此我们提醒您，如果可能的话，您应该尝试通过避免复合名词来避免此问题，因为它通过使用一些创造性的名称间距来避免复合名词。
但是，还会有更多的词根出现，您会发现一个复合名词，例如在URL中使用kebab case表示检查运行，而在使用snake case的情况下使用JSON主体。
条纹
URL和JSON正文中的Stripe使用蛇形大小写。 例如
PaymentsIntents API 。
https://api.stripe.com/v1/payment_intents和JSON主体...
{"id": "pi_Aabcxyz01aDfoo","object": "payment_intent","allowed_source_types": ["card"],"amount": 1099,"amount_capturable": 1000,贝宝
贝宝（Paypal）具有比其他检查的API更多的复合名词。 用于资源（例如计费协议）的API，该API将在网址中使用kebab大小写，然后在JSON有效负载中使用蛇形大小写。
推特
Twitter在URL中使用蛇形（例如/ saved_searches /），在JSON负载中使用蛇形。
脸书
Facebook的Graph API倾向于避免URL中的资源命名，而在JSON主体中则是蛇形。
在这一阶段，您应该会有点困惑。 因此，让我们回顾一下下表。
| API | 网址 | JSON正文 | |
|---|---|---|---|
| AWS API网关 | 没有分隔符 | 骆驼香烟盒 | |
| Facebook Graph API | 不适用 | snake_case | |
| Github | 蛇和烤肉串 | snake_case | |
| Google自定义搜索 | 没有分隔符 | 骆驼香烟盒 | |
| Google Gmail | 骆驼香烟盒 | 骆驼香烟盒 | |
| 领英 | 骆驼香烟盒 | 骆驼香烟盒 | |
| 支付宝 | 烤肉串 | snake_case | |
| 条纹 | snake_case | snake_case | |
| 推特 | snake_case | snake_case |
每个人都不一样，该怎么办？
因此，整个行业缺乏一致性。 但是，有一点值得提出：
- 通常，最好避免使用复合名词。 在所有已检查的API（贝宝除外）中，它们均出现在5％以下的API中。 这意味着当不使用他们喜欢的方法时，开发人员不会感到沮丧。
- 在上面的选择中，唯一使用复合名词的API超过5％的Web API是PayPal，它们在URI中使用kebab-case。
- kebab-case从未在任何JSON主体中使用。 允许使用语法。 那么，什么驱动了这一趋势？ 这很有可能是因为JavaScript Web UI可能是受mos最受欢迎的客户端调用API，并且类似地，为该API提供服务的最流行的后端语言是Java，而这两个家伙在它们的任何声明中均不允许。
做决定
- 如果可以，请避免使用复合名词。 这并不总是可能的。 坚持使用无处不在的语言非常重要且很有帮助。 如果您有复杂的业务应用程序，则将有很多复合名词。
- 如果您无法避免复合名词，并且超过5％的API将涉及复合名词，请使用kebab大小写作为URI。 为什么？ 因为如果您具有复杂的业务领域，则不仅需要考虑开发人员。 许多BA，产品架构师，好奇的经理也将关注您的API。 烤肉架案例是每个人最容易阅读的案例。
- 对于JSON主体，我认为可以使用camelCase，因为这是最容易映射回JavaScript和Java代码的方法。 Google也建议在JSON中使用camelCase 。
- 如果必须在URI中使用camelCase，请考虑对URI使用首字母大写方法，因为URI应该标记资源而不是属性。 资源更类似于Java类，Java类也使用首字母大写格式。 JSON有效负载属性类似于使用初始小写字母的Java属性。
在下一次之前，请多保重。
翻译自: https://www.javacodegeeks.com/2018/12/whats-case-api.html
api 获取网络使用情况
)
