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 獲取網絡使用情況

總結

以上是生活随笔為你收集整理的api 获取网络使用情况_您的API是什么情况？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。