基于 API 的 SaaS 正当道！
我们正进入基于云的企业产品大行其道的新时代：这个时代让开发人员大施身手，并为未来基于互联网的软件构建基本模块。但是这一批没有用户界面的新产品并非没有一系列新的挑战。
构建、分发和使用企业软件的方式已出现了许多重大转变。从昔日的本地托管解决方案――确保高效运行就需要定制代码和顾问团队，到如今基于云的解决方案，专注于出色的用户体验、几乎不需要用户导入（onboarding）工作，以及为客户极其灵活地确定价格。
但是就在全世界清醒地认识到设计和用户体验对企业产品的重要性时，可能是在消费者市场出现同样的变化多年后，如今出现了新一代B2B解决方案，它们完全摈弃了视觉用户体验，那就是基于API的SaaS。
这类服务有几个很难忽视的特点：
没有用户界面（GUI）。或者在一些情况下，虽然有GUI，但是对核心产品而言是次要的。
与服务的交互通过基于Web的API来完成――这种编程方法以一种机器可读的方式连接服务，并且跨互联网传输数据。
服务的价值通常在于通过API提供的数据中。
价格常常基于使用量，这意味着成本基于对API提出的请求数量来核计。
Clearbit
Clearbit在构建一套商业智能API，目的在于成为许多公司企业的商业智能后端。与大多数基于API的产品一样，其价值在于Clearbit通过一种简单、易于使用的界面提供的数据。
Clearbit的营销活动侧重于突出其数据对贵公司的价值。
Contentful
Contentful是新一代内容管理系统（CMS），它是为我们如今所处的多设备环境开发的，不像许多“传统”的CMS产品。它如何管理这项服务？当然是通过API！Contentful团队已消除了在与设备无关的空间管理内容方面的大量复杂性。
Contentful强烈传达了可以轻松消除传统CMS的“遗留”部分这个好处。
Twilio
看起来Twilio势必会成为率先在2016年首发上市（IPO）的真正基于API的SaaS厂商。自2009年首次融资以来，其平台在这些年取得了长足进展，如今为可口可乐、优步和EMC等大公司运行电信基础设施。这一切通过API来实现！
Twilio的营销活动高度面向开发人员。
Algolia
Algolia提供了用于搜索的API，它让SaaS厂商得以有效地将处理应用程序中的高级、高性能搜索这项复杂工作交给外人处理――这从技术上来说很难实现。ProductHunt、Medium和Birchbox等应用程序中的搜索功能都基于Algolia！
Algolia在这种方面做得很到位：以一种交互式、吸引人的方式展示其产品的价值。
基于API的产品具有粘性
一旦集成到你的平台中，剥离并换掉某项功能确实很“麻烦”，无论是换成另一种产品，还是换成你自己的业务逻辑（自己的业务逻辑势必需要由你的技术团队来开发）。这可能意味着，即使明明有一种成本更低或功能出色的解决方案，可能仍然没有足够的动机改用这样一种竞争解决方案。
更专注于提供的价值
很难围绕基于API的产品添加“营销噱头”。因而，客户清楚地看到解决方案给其公司添加的价值来得极其容易，尤其是解决方案在为他们提供一些数据时。
更容易构建和维护
如果你在构建一款基于API的SaaS产品，有几个重要方面你不需要考虑，比如说：
设计完美的用户界面
适合多种浏览器和屏幕尺寸
创建应用程序内的用户导入及教程
构建原生移动应用程序
当然了，这并不是说有了API，一切来得更容易（参阅下面介绍的挑战），但是你有了大好的机会，可以运行一套基本上简化的软件架构，这套软件架构可以灵活扩展，适应数量庞大的请求。
客户可以使用自己的用户体验
使用你API的公司对于这种功能如何提供给用户拥有极大的控制权。他们在打上品牌推销时可以确保符合其产品的创新愿景，因而总体上提高体验的一致性。
用户导入
如果说用户导入的目的是，让你的客户尽快遇到“灵光一闪的时刻”（Aha moment），如果在“灵光一闪的时刻”到来之前，需要客户花时间来开发集成你的API，这可能具有挑战性。破坏导入体验的风险要大得多。
我采访了Contentful的首席执行官萨斯恰·科尼琴克（Sascha Konietzke），请他谈谈构建和完善基于API的产品时面临的一些挑战，尤其是导入客户时。下面是他所说的一番话：
“想针对以API为中心的产品导入客户大不一样。开发人员不想要强迫性的点击教程，而是想要立即使用你的API。既要以快速上手的说明文档和示例代码来支持他们，还要尽快帮助他们消除障碍。”
克服用户导入这个挑战的一个常见策略就是，提供与现有平台集成的一系列机制。
这在API有一系列很常见的用例（use case），它们需要与现有服务集成起来的情况下尤其有用。你实际上要做构建集成机制的工作，那样客户就没必要做这项工作。最终结果常常是“一键式”连接，而不是耗费几周的时间来开发和测试。
例子：Clearbit提供了预先构建的机制，与Google Sheets、Close.io、Salesforce、Marketo和Slack集成起来。
更长的销售周期
这与用户导入方面的差异直接有关。说服客户致力于集成API，并将所需的工作塞入到其开发周期，显然比说服他们点击漂亮的用户界面中的注册按钮、输入详细的支付资料来得更有难度。
你还需要考虑延长产品试用期，顾及用户导入方面增加的工作量。
定价缺乏灵活性
服务定价方面的选择要少得多。通常就面向数据的服务而言，你会看到灵活的基于使用量的定价，也就是按你对API提出请求的数量来定价。产品拆成基于API的微服务时，你会发现定价模式很难根据功能特性或其他因素来进行扩展。
说到有利方面，你面临的将是一组比较小的产品，每个产品有各自的、较灵活的定价体系，而不是一种产品有许多不同的价位。这样一来，客户就可以从解决方案中自行选择他们需要的不同部分，只要为他们看重的那部分付费即可。
例子：Contentful的定价依据是你用它们来存储的数据项数量，以及你对API提出请求的数量。
营销根本不直观
说到推销SaaS产品，主要在于想方设法传达和呈现解决方案给目标客户带来的价值。就算你的产品有一个高度直观、设计精良的用户界面，即使在最好的情况下，这项工作也并非易事。但是如果完全消除那个用户界面，你几乎没有什么办法来真正将产品呈现给目标客户。有什么解决办法？你不得不设法呈现产品提供的价值，而不是呈现产品本身。
你还可能不仅要向企业主和决策者进行推销，还要向开发人员进行推销，他们将是面临集成你的API这项任务的群体。如果你果真想要销售自己的产品，一定要赢得这两个群体的芳心。
例子：Twilio全力支持开发者大会、奖品和全面的知识库（知识库里面有众多代码示例和交互式集成指南），以赢得开发人员的芳心。
所以，这点很清楚：销售和使用基于API的产品有显著的好处。但是如果你已经在提供一种“全面”的SaaS解决方案，该如何是好？应该考虑把这种解决方案的部分作为独立服务来提供吗？下面是你应该先要考虑的几个问题。
我的产品哪些方面可以细分成更小的独立服务？
你的产品有没有小的方面可以为客户提供某种独立的价值？这些方面很适合通过API拆散并单独提供。
我的产品其价值是否与它提供的数据密切相关？
如果答案是“肯定”的，你可能应该考虑让客户以编程方式（通过API）来访问这些数据，并让客户能够在你数据的基础上构建平台和服务。
我的产品常常用作客户的解决方案的一个核心部分吗？
如果是这种情况，你又看到公司客户在你解决方案的基础上创造额外的价值，如果你通过API来提供你产品的这个部分，客户也许更容易做到这一点。许多SaaS公司的终极梦想就是成为平台或生态系统――你只要看一下Salesforce AppExchange（https://appexchange.salesforce.com），就明白这发掘了无限的可能性。
总的来说，SaaS公司通过API提供价值这股动向似乎不是什么重大动向。将来始终需要可以被人使用的产品和服务，他们可以借助某种界面与产品或服务进行交互。
然而，当“下一代”初创公司面对利用有限的资金和时间来构建产品这项艰巨的任务时，有一种新的方案可供它们选择：
使用API SaaS A作为我的电子邮件系统
使用API SaaS B作为我的支持系统
使用API SaaS C作为我的商业智能系统
等等
而到时我们有新一代SaaS，使用一系列基于API的现有服务的基本模块来构建，这新一代SaaS能够：
更迅速地发布产品；
添加一部分高级功能，又不需要内部专长（比如机器学习）；
更准确地评估其服务的成本；
更可靠地扩展。
我们已经看到了这一幕，甚至从一些地位比较牢固的初创公司身上。不过，我们可能会在未来几年在更多的公司身上看到这一幕，到时越来越多的部分功能适合通过API来“外包”。
现在剩下来的唯一问题说：“要说有什么区别的话，5年后，还有什么仍会从头开始来构建？”
云头条编译｜未经授权谢绝转载
相关阅读：
SaaS交流群欢迎加入，群主微信：aclood