Before I learned software development, API sounded like a kind of beer.
在我學習軟體開發之前，API聽起來就像啤酒。
Today I use the term so often that I have in fact recently tried to order an API at a bar.
在今天我頻繁地使用這個術語，以至於我最近在酒吧點了一杯API。
The bartender’s response was to throw a 404: resource not found.
調酒師的反應是拋出404:資源未找到。（大概就是黑人問號臉）
I meet lots of people, both working in tech and elsewhere, who have a rather vague or incorrect idea about what this fairly common term means.
我遇到很多人，包括在科技行業和其他行業工作的人，他們對這個相當常見的術語的含義有相當模糊或錯誤的想法。
Technically, API stands for Application Programming Interface. At some point or another, most large companies have built APIs for their customers, or for internal use.
從技術上講，API代表應用程式編程接口。在某種程度上，大多數大公司都為客戶或內部使用構建了api。
But how do you explain API in plain English? And is there a broader meaning than the one used in development and business? First, let’s pull back and look at how the web itself works.
但是如何用簡單的英語解釋API呢?還有比開發和業務中使用的含義更廣泛的含義嗎?首先，讓我們回顧一下web本身是如何工作的。
WWW and remote servers
When I think about the Web, I imagine a large network of connected servers.
當我想到Web時，我想像一個由連接的伺服器組成的大型網絡。
Every page on the internet is stored somewhere on a remote server. A remote server is not so mystical after all — it’s just a part of a remotely located computer that is optimized to process requests.
網際網路上的每個頁面都存儲在遠程伺服器的某個位置。遠程伺服器一點也不神秘——它只是遠程計算機的一部分，用於優化處理請求。
To put things in perspective, you can spin up a server on your laptop capable of serving an entire website to the Web (in fact, a local server is what engineers use to develop websites before releasing them to the public).
客觀地說，你可以在你的筆記本電腦上啟動一個伺服器，該伺服器能夠將整個網站服務於Web(實際上，工程師在向公眾發布網站之前使用本地伺服器來開發網站)。
When you type www.facebook.com into your browser, a request goes out to Facebook’s remote server. Once your browser receives the response, it interprets the code and displays the page.
當你在瀏覽器中輸入www.facebook.com時，一個請求就會發送到Facebook的遠程伺服器。一旦瀏覽器接收到響應，它將解釋代碼並顯示頁面。
To the browser, also known as the client, Facebook’s server is an API. This means that every time you visit a page on the Web, you interact with some remote server’s API.
對於瀏覽器，也稱為客戶端，Facebook的伺服器是一個API。這意味著每次訪問Web頁面時，您都要與某個遠程伺服器的API進行交互。
An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses.
API與遠程伺服器不同——它是伺服器接收請求和發送響應的部分。
APIs as a way to serve your customers
You』ve probably heard of companies packaging APIs as products. For example, Weather Underground sells access to its weather data API.
API是服務客戶的一種方式
你可能聽說過將api打包為產品的公司。例如，Weather Underground出售對其天氣數據API的訪問權。
Example scenario: Your small business’s website has a form used to sign clients up for appointments. You want to give your clients the ability to automatically create a Google calendar event with the details for that appointment.
示例場景:你的企業網站有一個用於為客戶註冊預約的表單。你希望讓你的客戶端能夠自動創建帶有該約會詳細信息的谷歌日曆事件。
API use: The idea is to have your website’s server talk directly to Google’s server with a request to create an event with the given details. Your server would then receive Google’s response, process it, and send back relevant information to the browser, such as a confirmation message to the user.
API的使用:這個想法是讓你的網站的伺服器直接與谷歌的伺服器進行對話，請求用給定的細節創建一個事件。然後，你的伺服器將接收谷歌的響應，處理它，並將相關信息發送回瀏覽器，例如發送給用戶的確認消息。
Alternatively, your browser can often send an API request directly to Google’s server bypassing your server.
或者，您的瀏覽器通常可以繞過您的伺服器直接向谷歌的伺服器發送API請求。
How is this Google Calendar’s API different from the API of any other remote server out there?
這個谷歌日曆的API與其他遠程伺服器的API有什麼不同?
In technical terms, the difference is the format of the request and the response.
在技術術語中，區別在於請求和響應的格式。
To render the whole web page, your browser expects a response in HTML, which contains presentational code, while Google Calendar’s API call would just return the data — likely in a format like JSON.
要呈現整個web頁面，瀏覽器需要HTML格式的響應，其中包含表示代碼，而谷歌Calendar的API調用只返回數據—可能是JSON格式。
If your website’s server is making the API request, then your website’s server is the client (similar to your browser being the client when you use it to navigate to a website).
如果你的網站伺服器發出API請求，那麼你的網站伺服器就是客戶端(類似於您的瀏覽器在使用它導航到網站時是客戶端)。
From your users perspective, APIs allow them to complete the action without leaving your website.
從用戶的角度來看，API允許他們在不離開網站的情況下完成操作。
Most modern websites consume at least some third-party APIs.
大多數現代網站至少使用一些第三方api。
Many problems already have a third-party solution, be it in the form of a library or service. It’s often just easier and more reliable to use an existing solution.
許多問題已經有了第三方解決方案，可以是庫或服務的形式。使用現有的解決方案通常更容易、更可靠。
It’s not uncommon for development teams to break up their application into multiple servers that talk to each other via APIs. The servers that perform helper functions for the main application server are commonly referred to as microservices.
對於開發團隊來說，將他們的應用程式分解成多個通過api相互通信的伺服器並不少見。為主應用伺服器執行輔助功能的伺服器通常稱為微服務。
To summarize, when a company offers an API to their customers, it just means that they』ve built a set of dedicated URLs that return pure data responses — meaning the responses won’t contain the kind of presentational overhead that you would expect in a graphical user interface like a website.
總而言之，當一家公司向其客戶提供API時，這僅僅意味著他們構建了一組返回純數據響應的專用url——這意味著響應不會包含你在像網站這樣的圖形用戶界面中所期望的表示開銷。
Can you make these requests with your browser? Often, yes. Since the actual HTTP transmission happens in text, your browser will always do the best it can to display the response.
你可以在瀏覽器中發出這些請求嗎?通常,是的。由於實際的HTTP傳輸是在文本中進行的，因此瀏覽器將始終盡力顯示響應。
For example, you can access GitHub’s API directly with your browser without even needing an access token. Here’s the JSON response you get when you visit a GitHub user’s API route in your browser (https://api.github.com/users/petrgazarov):
例如，你可以使用瀏覽器直接訪問GitHub的API，甚至不需要訪問令牌。下面是當你在瀏覽器中訪問GitHub用戶的API路由時所得到的JSON響應 (https://api.github.com/users/petrgazarov)：
The browser seems to have done just fine displaying a JSON response. A JSON response like this is ready for use in your code. It『s easy to extract data from this text. Then you can do whatever you want with the data.
瀏覽器似乎已經很好地顯示了JSON響應。這樣的JSON響應可以在代碼中使用。從文本中提取數據很容易。然後你可以對數據做任何你想做的事情。
A is for 「Application」
To close off, let’s throw in a couple more examples of APIs.
最後，讓我們再看幾個api示例。
「Application」 can refer to many things. Here are some of them in the context of API:
「應用」可以指很多東西。以下是API環境下的一些例子:
1、A piece of software with a distinct function.
1、一種功能獨特的軟體。
2、The whole server, the whole app, or just a small part of an app.
2、整個伺服器，整個應用，或應用的一小部分。
Basically any piece of software that can be distinctively separated from its environment, can be an 「A」 in API, and will probably also have some sort of API.
基本上，任何軟體都可以與它的環境區別開來，可以是API中的「A」，並且可能也會有某種API。
Let’s say you’re using a third-party library in your code. Once incorporated into your code, a library becomes part of your overall app. Being a distinct piece of software, the library would likely have an API which allows it to interact with the rest of your code.
假設你在代碼中使用第三方庫。一旦你的代碼中包含了一個庫，它就會成為你整個應用程式的一部分。作為一個獨立的軟體，這個庫可能會有一個API，它可以與你的其他代碼進行交互。
Here’s another example: In Object Oriented Design, code is organized into objects. Your application may have hundreds of objects defined that can interact with one another.
下面是另一個例子:在面向對象的設計中，代碼被組織成對象。你的應用程式可能定義了數百個可以相互交互的對象
Each object has an API — a set of public methods and properties that it uses to interact with other objects in your application.
每個對象都有一個API——一組用於與應用程式中的其他對象交互的公共方法和屬性。
An object may also have inner logic that is private, meaning that it’s hidden from the outside scope (and not an API).
對象也可能具有私有的內部邏輯，這意味著它隱藏在外部範圍之外(而不是API)
From what we have covered, I hope you take away the broader meaning of API as well as the more common uses of the term today.
從我們已經討論過的內容中，我希望您能夠理解API的更廣泛含義以及這個術語現在更常用的用法。
完
Interesting Resources (stuff that I left out but is still very cool):
有趣的資源(我省略了但仍然很酷的東西)：
about DNS：https://www.youtube.com/watch?v=72snZctFFtA&feature=youtu.be
about HTTP：https://simple.wikipedia.org/wiki/Hypertext_Transfer_Protocol