上一篇認識了 HTTP、Request 和 Response，知道前端有事情需要後端處理時，可以發出 Request，後端處理完之後，再透過 Response 把結果回傳給前端。

不過這時候又有一個問題：

前端發出的 Request，到底要送到後端的哪裡呢？

繼續用前幾篇提到的登入來看。

當我們在前端輸入帳號和密碼並按下登入後，前端會發出一個登入的 Request，並把它送到後端 API 中對應的 Endpoint，接著由後端處理登入，再把結果回傳給前端。

那這裡提到的 API 和 Endpoint 到底是什麼？

API 是什麼？

API = Application Programming Interface（應用程式介面）。

第一次聽到 API 的時候，為了讓我們比較好理解，學長把它解釋成「前端與後端的連接處」。

不過更準確一點來說，在我們現在的前後端情境中，可以先把 API 理解成：

後端提供給前端使用功能的介面。

例如登入這件事，真正處理登入的是後端，而前端可以透過後端提供的 API 來使用登入功能。

前端不需要知道後端裡面的程式到底怎麼寫，只需要按照 API 提供的方式發出 Request，就可以使用後端提供的功能。

不過一個 API 裡通常不會只有一種東西要處理，可能會有登入、使用者、作業等等。

那 Request 要怎麼知道自己應該送到哪裡？

這時候就會遇到 Endpoint。

Endpoint 是什麼？

Endpoint（端點）可以先簡單理解成 API 中接收 Request 的特定位置。

例如可能會有：

/login → 跟登入有關
/users → 跟使用者有關
/tasks → 跟作業有關

這樣看起來其實有點像是在「分類」。

如果把它想成大標題，/tasks 就有點像「作業」這個大標題。

當 Request 送到 /tasks 時，可以先理解成是在告訴後端：

「我這次要處理的東西跟作業有關。」

不過 Endpoint 並不是專門拿來分類的，而是讓 Request 知道要送到哪個位置。
只是不同的 Endpoint 通常會對應不同的東西，所以看起來會有一點像是在分類。

到這裡可以先簡單整理：

API：後端提供給其他程式使用功能的介面。
Endpoint：API 中接收 Request 的特定位置。

不過現在又有一個問題。

就算後端知道 Request 是送到 /tasks，也只知道這次跟「作業」有關。

那它要怎麼知道我們是想：

取得作業？新增作業？修改作業？還是刪除作業？

這就是下一篇要介紹的 GET、POST、PUT、DELETE。