您是否對客戶不屑一顧？您希望他們會消失嗎？當您與客戶互動時，您是在默默地幻想著他們轉向競爭對手的產品嗎？簡而言之，您討厭客戶嗎？

也許您應該嘗試使用公司的外部API來表示不屑。什麼？你怎麼能做到這一點？

在本文中，我記錄了許多行業最佳實踐，旨在向客戶展示您有多討厭他們。它們都很容易實現。哎呀，您的公司可能已經在做了許多。

基本原理

您為什麼要使用公司的API表示仇恨？我認為答案很簡單：客戶是混蛋。

該死的客戶！始終使用我們的服務！打擾我們的銷售人員報價！匯款給我們，為應收帳款部門創造了更多的工作。出於愚蠢的原因而需要客戶支援，例如：“文件錯誤”或“此功能已損壞”或“您的產品殺死了我的貓”。

混蛋

年齡大的人可能渴望擁有過去的美好時光，那時實際上是真正壟斷的公司會假裝愛他們的客戶。現在，我們所有人都為那些不承認壟斷而實際上討厭客戶的公司工作，但是孩子，時代變了！

技術＃1：沒有API

無論如何，API有什麼用？首先，它允許客戶實施您沒有想到的功能。

API還允許客戶使用更多產品。如果存在API，他們可以自動使用您的產品，這將使他們更多地使用它。他們可以自動為整個公司配置資源。他們可以根據您的API構建全新的應用程式。試想一下，使用API​​可以消費多少您的產品。

多麼無禮！如果他們更多地使用您的產品，則您將不得不購買更多的伺服器，花費更多的時間兌現支票。

技術＃2：使註冊困難

好的，您已經輸掉了戰役，而您的公司仍然想構建一個API。至少您可以通過複雜的註冊過程來稍微踩一下剎車。

有多種方法可以使客戶的登入工作繁重。一些公司要求您開啟一個授權ticket或與真實的人交談。這會使所有內向的開發人員在使用API​​之前都要三思。

一些公司希望您填寫一份申請表，以便能夠編寫一份申請表。讓人們乞求使用您的產品是阻止新使用者的好方法。

為了獲得最佳結果，此類表格上的問題應由以前曾擔任CIA詢問者的人撰寫：為什麼要使用此API？您的應用程式將做什麼？12日晚上您在哪裡？你母親的孃家姓什麼？你能證明她真的是你母親嗎？

我填寫的一份此類表格要求我描述計劃編寫的應用程式。六個月後，一個特警稽核組出現在我家，要求我向他們展示我的密碼。他們想證明我沒有撒謊。如果我的申請與我的申請不匹配，那麼我可能會被送進監獄。

好吧，那不是真實的故事。但是，我確實曾經在表格上看到該問題。可悲的是，我沒有特定的應用程式。我將探索API並編寫一些基於Python的簡單實用程式來自動化一些日常任務。但是，我不想解釋所有這一切，因為擔心我的答案對於判斷我的申請的人來說不夠好。慌亂中，我只是將應用程式描述為“深紫色，帶有白色高光”。幾周後，我的申請被批准了。到目前為止，我還沒有任何稽核員SWAT團隊訪問過我，但是為預防起見，我的程式碼編輯器此後一直以深紫色和白色高亮為主題。

可悲的是，有些公司不瞭解如何增加註冊難度。他們要麼使流程完全自助服務，要麼根本不需要任何型別的註冊流程。他們什麼時候會學？

技巧3：額外收費，很多。

還記得行動電話公司何時為2美元的資料線收取100美元的費用嗎？API為什麼不能這樣？您可能會向敢於有效使用您的產品的任何人收取附加費。不要浪費這個機會！

通常對您的服務收費，或者僅在“企業版”中包含API訪問許可權。實際上，這是阻止垃圾郵件傳送者或其他濫用服務的人的好方法。

使其成為收入來源，而不是鼓勵人們使用您的產品的方式。使API訪問如此昂貴，以至於銷售部門認為API代表了額外的利潤激勵。

技術＃4：從搜尋引擎隱藏API文件

如果您的API文件沒有出現在搜尋引擎中，則說明您已將客戶帶回過去。幸運的是，可以通過將文件放在登入螢幕後輕鬆完成此操作。如果Google無法抓取它，則它無法將其編入索引。搜尋有關您的API的答案將是不可能的。

需要某種註冊或登入來訪問您的API文件，也可以防止您的競爭對手檢查API並從中學習。沒有競爭對手曾經考慮過使用其家庭住址進行註冊，或與朋友共享密碼，對嗎？決不。他們不是那麼聰明。它永遠不可能發生。當然，您永遠不會那樣做，為什麼要這麼做呢？

技術5：使用可怕的協議

許多API使用JSON：API（jsonapi.org）或JSON-RPC（jsonrpc.org）。它們輕巧，易於使用且易於除錯。

要真正讓您的客戶不屑一顧使用你的API，請使用專有協議，以使語言支援僅限於您提供的客戶端庫，最好是永遠不會更新的二進位制Blob。如果精心設計，專有協議也可能難以理解且無法除錯。

或者，您可以使用SOAP（簡單物件訪問協議）。根據Wikipedia的說法，SOAP“可能會腫且過於冗長，從而使其佔用大量頻寬且速度很慢。它還基於XML，因此解析和處理起來特別昂貴，尤其是在移動或嵌入式客戶端上”聽起來像雙贏！

技術＃6：只允許一個API金鑰

我最喜歡對客戶表示鄙視的一種方式是一次只允許一個API金鑰。您要做的使客戶的工作充滿辛勞和認知負擔的任何事情都會說：“我不在乎您。”

API金鑰基本上是用於標識和認證客戶的密碼。您的電子郵件帳戶只有一個密碼；為什麼您需要多個？那會很奇怪，對吧？

最終，客戶將需要更改或“旋轉”他們的API金鑰。也許是洩漏了。也許某個員工離開了公司並擁有了鑰匙的副本。也許他們只需要每年更換一次金鑰，作為其安全策略的一部分。

技術＃7：手動維護文件

隨著API的發展，API和文件可能會不同步。沒有什麼比建立一個鼓勵這種錯誤的系統更能說明“我不在乎使用者了”。

當然，有諸如Swagger（https://swagger.io/tools/open-source/）和gRPC（http://www.grpc.io）之類的系統可以讓您在一處定義API及其文件。自動生成多種語言的文件，伺服器存根，客戶端SDK繫結等。但是，一次完成工作並讓計算機免費生成您需要的所有下游工件有什麼樂趣呢？一致性是為了簡單。

技術＃8：忽略IaC革命

將基礎架構視為程式碼（IaC）的能力已成為運營團隊的頭等大事。它不僅使操作更容易，更可測試且更可靠，而且為SOC2（服務組織控制）和PCI（支付卡行業）之類的安全合規性最佳實踐鋪平了道路。

一些公司浪費時間使客戶更容易做到這一點。他們提供了官方支援的模組，可從Terraform，Ansible，Chef，Puppet和類似系統訪問其服務。通過託管用於多個Linux發行版的儲存庫，他們使客戶端軟體易於使用，並且它們提供Chocolatey feed，以便在Windows上輕鬆安裝。

忽略所有這些技術，並希望開源社群能夠提供，要容易得多。是的，這可能會導致混亂的不相容選項，但是您可以大呼“使用者選擇”的好處。

技術＃9：不要冪等

如果多次執行操作產生與完全執行一次相同的結果，則該操作是冪等的。

假設有一個建立虛擬機器（VM）的API呼叫。如果此API呼叫是冪等的，則我們首次將其稱為VM。第二次呼叫它時，系統檢測到該虛擬機器已經存在，並且僅返回而沒有錯誤。如果此API呼叫不是冪等的，則呼叫10次將導致建立10個VM。（注意：冪等的對立面不是有效的。）

同樣，冪等刪除呼叫將刪除該物件。隨後的呼叫將安靜地執行任何操作並返回成功狀態程式碼。如果呼叫是非冪等的，則第二個呼叫將返回“未找到”錯誤，這將使開發人員感到困惑，並可能使他們質疑存在的意義。

為什麼有人會多次呼叫相同的API？重試。在處理RPC（遠端過程呼叫）時，響應可能是成功，失敗或根本沒有響應。如果沒有收到伺服器的迴音，則必須重試該請求。

使用冪等協議，您可以簡單地重新傳送請求。使用非冪等協議，必須在每個操作之後加上程式碼，這些程式碼可以發現當前狀態並進行正確的恢復。將所有恢復邏輯放在客戶端中是一種分層衝突。

在虛擬機器示例中，您將必須查詢清單，並檢視要求建立的虛擬機器是否存在。如果確實存在，則必須確保其建立正確或處於良好狀態。如果狀態不好，請修復或刪除它，然後重新開始。潛在條件和邊緣情況的清單不勝列舉。

那是一個簡單的例子。從其他API呼叫中恢復可能會更加複雜。從故障中恢復的嘗試也可能會失敗。現在，您將面臨著無限遞迴的失敗，失敗的恢復嘗試以及不斷的失敗。乍一看看上去很明智的程式碼最終會建立零個VM，或三個或更多VM。對於多個同時存在的客戶端，您必須處理時間安排，鎖定問題，交叉訊息以及大量的問題。

當API是冪等時，可以減少或消除這些問題。

為什麼不簡單地使用更可靠的網路？哦，那真可愛。網路永遠都不可靠。他們不可能。認為網路可靠是分散式計算的第一個謬論（https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing）。

如果網路不可靠，那麼網路API本身也就不可靠。請求到伺服器的途中可能會丟失，並且永遠不會執行。執行可能已經完成，但是回覆我們的資訊卻丟失了。在操作過程中，伺服器可能會重新引導。客戶端可以在傳送請求，等待請求時或在接收到請求之後但在本地狀態儲存到穩定儲存之前重新引導。這麼多邊緣案例！

在分散式計算中，一切都會失敗。如果您討厭客戶，則可以確保處理故障是繁重的，容易出錯的，而且根本不可能100％正確地做到。客戶將始終在固定前沿案例，而不是從事富有成效的工作。

不要破壞樂趣。向使用非冪等API的客戶展示您的不屑一顧。

總結

本文以開玩笑為重點。儘管有些公司這樣做是在做壞事，但並不是為了傷害客戶。以我的經驗，工程師以出色的工作和出色的系統給客戶留下深刻的印象而感到自豪。我相信，當公司做本文中的頑皮事情時，那是出於無知，缺乏資源或不可能的截止日期。

幸運的是，在某些情況下，良好實踐要比不良實踐更容易實現。建立驗證系統以限制對文件的訪問比免費提供文件更加困難。將所有文件放在一個較長的頁面上，以便可以使用Ctrl-F進行搜尋，比將每個API呼叫放在單獨的頁面上要容易得多。

可悲的是，其中一些良好實踐確實需要大量工作。建立自助式入職系統並不容易。它需要對可用性測試和修訂進行多次迭代。第一次猜測永遠不會實現易用性。

證明所有這些良好做法所需的資源可能很困難，尤其是當許多客戶不使用API​​時。“幾乎沒有人使用我們的API時，投資回報率是多少？” 您的管理層可能會問。我的看法有所不同：也許使用率很低，因為您還沒有做這些事情。