您是否对客户不屑一顾？您希望他们会消失吗？当您与客户互动时，您是在默默地幻想着他们转向竞争对手的产品吗？简而言之，您讨厌客户吗？
也许您应该尝试使用公司的外部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时，投资回报率是多少？” 您的管理层可能会问。我的看法有所不同：也许使用率很低，因为您还没有做这些事情。