【第1772期】从拉面店的贩卖机理解什么是 API

前言

又是一篇通过故事化形式通俗讲解技术。今日早读文章由@胡立分享。

正文从这开始～～

API，全名叫做 Application Programming Interface，维基百科上的中文翻译是：「应用程式界面」。这是一个你可能听过很多次，但从来没有理解过的东西，常常听到工程师说著：「串 API」，但还是不知道 API 到底是什么。

我原本以为在网络上有关 API 的参考资料已经有很多了，应该可以让初学者理解什么是 API。但根据我学生们的心得，好像还是有点困难，只好自己跳下来写一篇，试着来挑战这个主题，希望写出一篇浅显易懂的 API 介绍文。

如果你问我什么是 API，我会跟你说：「API 就是拉面店的贩卖机」，所以在切入正题之前，我们要先来研究一下日本拉面店会出现的贩卖机。

仔细地研究一下贩卖机

你有去日本玩过吗？或其实现在有些台湾的店家也用相同的方式来取代人力了。

上面的图片是贩卖餐券的贩卖机（我原本想拍一张更近一点的然后是拉面店的，但我离开日本才想到我忘记拍了…只好拿很久以前在东京都厅的餐厅拍的图片来补），每一个按钮就是一个商品，例如说咖哩饭、咖哩乌龙面、咖哩猪排饭等等，也有一些像是「份量加大」、「加蛋」之类的选项。

当你决定好要什么以后，就投钱进去，然后按下你要的选项的按钮，就会有张餐券掉出来，上面写着你所选的品项。简单来说呢，就是个贩售餐券的贩卖机，跟你平常买可乐买果汁的贩卖机大同小异。

拿到餐券之后呢，你就只要把它交给店员就好，店员就知道你要点什么餐了。接著就是坐等餐点煮好，开始享用丰盛的一餐。

我第一次去日本的时候体验到这种点餐方式觉得十分特别，但接下来我们要来想一下，它到底特别在哪里。为了回答这个问题，我们先来回忆一下原本点餐怎么点。

如果是跟以前一样在柜台点餐，帮你点餐的会是店员，然后你要跟店员说你要什么商品，也能够进一步定制化，例如说：「一份烧肉套餐不要烧肉」或者是「鸡排要切不要辣，炸酥一点，蒜多一点」，接着店员再透过电脑系统或者是直接跟内场说你要点什么。

那这跟我们用餐券贩卖机差在哪里呢？

固定商品

贩卖机的商品是固定的，上面没有的你点不到。没有一个地方可以让你输入定制化资讯，所以如果没有「不要姜」的按钮，你的餐券上面就不会有这项资讯，你就点不到没有姜的拉面（这边先不考虑直接跟店员说）。

减少沟通障碍

你沟通的对象从店员变成了机器，坏处就像上面说的一样，定制化程度有限，而好处就是没有沟通问题。你不会讲日文也没关系，反正按钮上有写英文或中文，就算没有也会有图片，你按按钮就可以点餐了，完全没有语言障碍。

简而言之，在你跟餐厅之间，你们透过贩卖机这个媒介来沟通。你跟贩卖机说你要什么，然后得出一张餐券，接着把这个餐券交给餐厅，餐厅就会处理剩下的事情并且把餐点给你。

这过程当中你一句话都不用说，只需要透过按按钮跟递餐券，就完成了点餐加付款的程序。

好，上面我们讲的都是以顾客的角度来看这件事，那接着我们来想想，为什么店家要导入贩卖机？导入贩卖机有什么好处？

节省人力

最直接能想到的一点就是节省人力，你只要买一台机器放在那边，就解决了点餐跟买单这两项作业，不用再放一个人到收银台那边，节省了一些人力成本。

而且对餐厅来说，原本点完餐之后店员要跟厨师说有什么单，现在变成餐券之后，其实餐券直接拿给厨师就好，他们就知道要煮什么了。

固定点餐选项，节省定制化所需成本

因为改用了餐券贩卖机，上面的选项都是你已经定好的，所以你不想提供的东西可以不放。

例如说你拉面就是一个 size 不能加大也不能缩小，上面就可以不放加大的按钮，客人也不用问你说：「面可以加大吗？」，因为贩卖机上面没有就是没有。也不用再处理那种牛肉面不要牛肉的情况，除非你自己在贩卖机上面放这个选项。

这样分析完之后，觉得贩卖机还真的是好处多多，难怪日本一堆店都用贩卖机来处理点餐跟买单，写完上面这段之后连我自己都想买一台放家里了。

但是，这到底跟 API 有什么关系？

别急，我们慢慢来嘛！先再来看一个故事再说。

民宿主人阿民的故事

阿民家里经营着民宿的生意，为了让大家更有画面感，这是房间的长相：

阿民在五岁那年，意识到爸妈每天都辛苦地用纸本纪录订房资讯，于是从那天起下定决心，要成为资工系的学生，帮家里写一个管理订房的网站，让爸妈开心。

时间快转到十几年后，他顺利地就读了资工系，除了系上教的那些科目，他也透过自学学习到了网页开发的技术，并且成功做出了一个民宿管理系统，取名为 MingBook.com，用来管理家里所经营的民宿。

这套系统成功地帮他们节省了很多时间，而且电子化之后爱护地球，从此以后都不必用纸本记录东西，只要在电脑上按几个键就好，十分方便。

不过，还有另一个更重要的问题还没被解决。

目前能订房的方式只有两个，一个是打电话，另一个是到 MingBook.com 的官网。换句话说，如果 SEO（Search Engine Optimization，搜索引擎优化） 做得不好，大家在使用 Google 搜寻民宿的时候找不到这个网站，就没有人知道这间民宿的存在了。

再这样下去，订单会越来越少，最后只能落得关门大吉的下场。阿民心想这样不行，决定想一些方法来解决这个问题。而他能想到最快也最直接的方法，就是把房间上架到订房网站。

对欸，如果上架到那些 a 开头 b 开头 h 开头的订房网站，不就会带更多流量进来吗？这样大家就有更多管道可以来订房间了，不再受限于电话跟民宿官网。

「喂？请问是某某知名订房网站吗？想请问一下我如果想把我们家的民宿在你们网站上架，应该要怎麽做？」阿民打了通电话，想说直接去询问应该怎么上架，会比较有效率点。

『主要就是两个资讯，第一个是您要提供空房资讯，我们才能在网站上显示。第二个是使用者下订单之后，必须提供一个方法让我们把订单传送到您那里』

「这很简单嘛，我们已经有订房网站了，是我自己写的。你只要去网站上面就可以看到空房资讯跟下订单了」阿民心想原来这么容易，当初写的系统还真好用。

『抱歉，我们要的只有资料，如果您提供的是一个网站，那我们工程师必须写爬虫去解析画面才能拿到资料。您必须提供 API 给我们喔，等你准备好 API 再到官网去填资料就好了，谢谢』

就这样，客服挂上了电话，留下一脸错愕的阿民：

到…到底什么是 API？

白话讲解 API

无论是明示或暗示，相信你在上面两个故事都有注意到一些我特别强调的地方。我发现如果要从正面来讲 API 会非常难讲，于是我决定先从侧面切入。

一般来说当我们提到 API，会是这样子的场景：

• 你 API 串好了没？你还没串的话资料拿不到欸

• 我要来串 Google 登入的 API，让我的网站可以用 Google 登入

• 请提供一个空房资讯的 API，我们才能显示在网页上面…

从以上对话可以看出 API 背后隐含了「交换资讯」的目的。换句话说，如果你今天一直是一个人单打独斗，自己做自己的，基本上就不太会有 API 这种事情。需要串 API，就代表你需要别人的资料，或者是别人需要你的资料。

这边特别把「资料」两个字 highlight 起来，就是因为 API 基本上只牵涉到资料的交换，这是很重要的一部分。就像是阿民跟订房网站的对话一样，虽然阿民在自家网站上已经有订房资讯了，但那个是 HTML，抓下来只会是一堆

之类的标签，不是「纯粹的资讯」。

那纯粹的资讯长什么样子？我们来看一下 GitHub 的 API，只要你在网址列输入：https://api.github.com/users/aszx87410 并按下 Enter，就可以看到这样的资讯：

你的第一个直觉可能是：「这什么看不懂的东西？」，但你仔细看，会发现内容其实你看得懂。例如说有一个 “location”: “Taipei, Taiwan”，大概猜得出来意思是「地点在台北」，而 “blog”: “https://medium.com/@hulitw” 也猜得出来是「blog 是这个网站」的意思。

上面这些就是「纯粹的资料」，你可以拿到资料本身，而不是画面。那什么叫做画面？这个就是画面：

在上图的画面中，我们一样可以看到各式各样的资讯，但这是因为我们是人。你如果拿给机器看，机器会跟你说：「维大力？义大利？」，不知道你在供三小。

那机器要看什么？要看我们上面用 GitHub API 回传的那些资讯，只有资料本身而没有任何画面，这才是机器想看而且读得懂的格式。所以，API 只会回传资料，而不是像上面这样的画面，这是很重要的一点。

举个例子，很多公司虽然都有后台系统可以看订单资料，但对于某些人来说，必须要加个输出成 Excel sheet 的功能，把资料都输出出来才行。为什么？因为我要的不是「看资料」，而是资料本身。我要把资料拿去做分析或是在 Excel 上面跑一些公式计算，所以我只需要资料。

所以简单来说，API 就是个拿来交换资料的东西。

为什么订房网站要阿民开放 API 出来？因为它需要民宿的空房资料。

应该怎么样才能在网站上用 Google 的登入功能？串 Google 的 API。

要怎样才能用代码操控印表机？用印表机提供的 API，就可以操控它。

当我提到「串 API」的时候，背后指的就是：「我要你的资料」或是「你要我的资料」，不过讲资料其实有点局限，更好的说法是：「我要用你的某个功能」或是「我要让你用我的某个功能」。

以 Google 登入 API 来说，我要串是因为「我想在我的网站上使用 Google 登入」，而 Google 「开放」出这个 API 是因为「Google 想让其他网站都可以用 Google 帐号登入」。

这边会特地把「开放」两个字标出来，意思就是说 Google 没有开放出来的功能，你就不能用。

咦，怎麽觉得这个概念跟开头讲的贩卖机有点像？

连结贩卖机与民宿网站的例子

仔细想想，会发现餐券贩卖机也是同样的。

为什么会有餐券贩卖机？废话，因为餐厅要卖东西啊，这样才叫做餐厅，提供食物以换取报酬。餐厅要卖食物，所以提供而且只提供餐券贩卖机这个介面让使用者来使用。

为什么在阿民的民宿网站必须提供 API 给订房网站？其中一个原因是阿民不可能把房间资讯的资料库直接给他们嘛，这样子顾客资料就全都外洩了。所以透过 API，阿民可以自己决定什么要对外开放。

这跟贩卖机是一样的，贩卖机上的按钮决定了你要卖什么餐点给顾客。如果今天没有贩卖机没有店员，你要让消费者自己衝进厨房跟厨师说他要点甚麽，你的独家配方都被看光了，你觉得有可能吗？

顾客透过贩卖机这个界面来点餐，就跟订房网站透过 API 才存取阿民家的房间资讯是一样的。这样你大概可以理解为什么 API 的重点是后面那个 I，Interface 了。

透过介面，可以把两端串连起来，却又让两端不会互相干扰。订房网站看得到MingBook.com 还剩几间房间，却看不到顾客资料。阿民可以知道订房网站上面自己的订单有哪些，可是没办法看到订房网站其他民宿的订单。

当阿民跟订房网站合作的时候，彼此之间会有资料交换的需求。但两方都不可能门户大开，直接把后台与资料库全部给对方看。这时候就需要 API，透过 API，来决定什么该开放，而什么又不该。开放的还可以觉得要开放到什么程度。

所以，什么是 API？为什么我们需要用到 API？

当「双方」需要交流的时候，就必须透过 API。而 API 就是一种…介面。听起来很抽象，但希望上面的那一大堆例子让你在说出「界面」这个词的时候脑中会有一些画面（至少把贩卖机想起来吧）

API 与 Web API

前面提到当双方交流的时候就必须透过 API，我觉得这算是很广义的定义了。今天当我在写程序时，我如果需要存取档案，我就必须透过作业系统提供的 API，才能存取到档案。如果今天作业系统没有给我这个 API，那我就存取不到。

上面我们提的这个是作业系统与程序语言这两层之间的 API，但是在一般生活上的例子，我们讲的 API 其实是「Web API」。

什么意思呢？

今天阿民跟订房网站要串接 API 来拿资料。阿民有阿民自己的网站，订房网站也有，那今天要透过什么在两个网站之间传递资料？网络嘛！透过网络才能传输资讯。

而因为是透过网络，所以就被称之为 Web API。你可以想成有很多种不同的 API，操控档案的我们会叫它 File API，网络相关的叫 Web API，诸如此类的。就像是贩卖机有很多种，卖餐券的叫餐券贩卖机，卖饮料的叫饮料贩卖机，但无论如何，它们全都是贩卖机。我们前面提到的那个网址：https://api.github.com/users/aszx87410，它其实就是一个 Web API，你透过网络连到这个网址，就可以拿到使用者 aszx87410 的资讯。所以我们可以说：「GitHub 开放了使用者资料的 API」，只要是任何想要取得使用者相关资讯的人，都可以来串接这个 API。

所以呢，阿民其实只要如法炮制，提供一个类似的东西，并且把内容换成房间的资讯就好。背后的实作就是从资料库把东西捞出来，然后按照一定格式输出，就大功告成了。当阿民把 API 做好并且在订房网站上面填写资料时，他必须提供什么？第一个就是网址，代表说：「这个 API 在哪里」，第二个则是文件，告诉对方这个 API 应该如何使用。这就像贩卖机一样，店家必须告诉我贩卖机在哪里，我才知道去哪里找它（好啦但通常都在门口），而贩卖机上面通常也都会有说明文字，跟我说怎麽操作，否则複杂一点的我有可能不会用。

API 在哪里（网址）、API 怎麽用（文件），这就是不可或缺的两大主角。

略过技术细节的 API 串接实战

接着我们来简单实战一下如何串接 API，不过我们不会讲到技术细节，只会讲到大概要做什么。如果想学会怎麽串接 Web API，你必须先知道什么是 HTTP 以及它在做什么，接著才是看 API 文件。在此篇文章中不打算讲这些，所以会简单带过。

假设今天我想串接 Spotify 的 API 好了，想取得最新专辑资讯，我应该怎麽做呢？首先，先透过 Google 搜寻：Spotify API，你会找到这个页面：

直接开门见山就跟你说是 Web API，就知道我们是要透过网络来跟 Spotify 拿资料。在这页面底下就会看到一些基本的说明之类的，但重点是上方导览列有个 Reference，点下去之后可以看见所有的资讯：

并且在左边的导览列中，可以看到 Browse 底下有个 Get a List of New Releases，看起来就是我们要的 API，再点下去可以看见介绍：

除了这截图以外，往下捲动还会有更多相关的资讯，而这就是一份完整的 API 文件，跟你说这个 API 在哪里（https://api.spotify.com/v1/browse/new-releases）以及如何使用（传什么参数、回传值是什么等等）。

不过与 GitHub API 不同，当你点击上面的网址时，会出现一个 No token provided 的错误，因为 Spotify 的 API 需要身份验证，而我们没有传进去相对应的身份验证，所以拿不到资料。

不过你在文件上面往下找可以看到范例输出，就可以看见这个 API 会回传的资料，的确是我们要的最新专辑相关资讯。

总结

API 是什么？就是日本拉面店卖餐券的贩卖机（会一直强调拉面店只是因为我第一次看到它是在拉面店）。

我要串接 API 来取得房间资讯

=> 我要看贩卖机来确定拉面卖完没

订房网站必须透过 API 来我的网站下订单

=> 顾客必须透过贩卖机来我的餐厅点餐

API 只给我 email 跟姓名，地址拿不到

=> 贩卖机只让我点拉面，没办法不要葱花

API 坏了，怎麽文件上写回传使用者资讯，却传成订单资讯？

=> 贩卖机坏了，怎麽按钮上面写酱油拉面，餐券却写烧肉饭？

什么是贩卖机？

是一台能让顾客与餐厅双方沟通的机器。

什么是 API？

是一个能让生产者与消费者双方沟通的界面。

希望看完这篇能够增进你对 API 的理解，从此再也不害怕这个名词。一看见 API 就会想到贩卖机，就会想到拉面，就会想到日本。

（结尾好想放个什么机票或是拉面的购买连结，就变成超展开的业配文了）

这篇文章预设的读者是完全不懂程式的路人或是有点程式基础的初心者，希望能够让他们更容易了解什么是 API。文中所用的贩卖机比喻并不一定能够适用所有跟 API 相关的场合，但我想强调的重点只有一个，那就是 API 是能够连接双方的界面。

关于本文 作者：@胡立 原文：https://medium.com/@hulitw/ramen-and-api-6238437dc544

他曾分享过

为你推荐