API 이해하기: 중요성 및 기능 설명

### API 이해하기: 기술에서의 기능과 중요성
* 📡 API는 애플리케이션 프로그래밍 인터페이스의 약자로, **요청과 응답을 통해 서로 다른 소프트웨어 애플리케이션 간의 통신**을 용이하게 합니다.
* 📞 API를 이해하기 위한 비유로 레스토랑의 고객 서비스에 비유할 수 있는데, 여기서 **API는 사용자가 시스템의 근본적인 복잡성을 이해할 필요 없이 요청을 할 수 있도록 중개자 역할**을 합니다.
* 🍽 API가 없다면 사용자가 서비스의 모든 세부 사항을 관리해야 하는데, 이는 **일반 사용자에게는 부담스러울 수 있고 전문 지식이 필요**할 수 있습니다.
* ☁ Apple의 날씨 앱이 자체 기상 관측소를 만들지 않고 **weather.com과 같은 기존 기상 데이터 서비스의 API**를 활용하는 것이 실제적인 예입니다.
* 🌐 API는 일반적으로 웹 프로토콜을 통해 작동하며, 인터넷을 통해 **JSON 또는 XML과 같은 형식**으로 요청과 응답을 전달하며, 각 상호 작용을 **API 호출**이라고 합니다.
* 🔗 요청에는 **서버 엔드포인트 URL과 수행할 작업을 정의하는 메서드(일반적으로 HTTP)**가 포함되며, 응답에는 **상태 코드와 관련 데이터**가 포함됩니다.
* ⚠ 익숙한 상태 코드로는 **404**가 있는데, 이는 요청된 URL을 찾을 수 없음을 나타내는 것으로 온라인에서 흔히 발생하는 오류입니다.
* 📚 API와 다양한 유형에 대해 더 깊이 이해하려면 **링크된 지수 문서와 같은 추가 리소스**를 살펴보는 것이 좋습니다.

API는 애플리케이션 간의 원활한 통신을 지원하여 복잡한 상호 작용과 데이터 액세스를 간소화합니다.

if you work in Tech or in anything adjacent to tech, you've probably heard the abbreviation API being thrown around, so let's talk about APIs. What are they and why do we need them? Let's start with what is an API. API stands for application programming interface. Fancy words, so let's break it

down. Application in this context just means any software that has a specific functionality or purpose. Interface refers to a contract or a protocol that dictates how two applications talk to each other using requests and responses. So put together, an API is simply a way for different systems or applications to

communicate with each other. Okay, cool in theory. So why do we need APIs? Let's start with a non-technical analogy first. Let's say you have a dinner reservation for tonight for three people, but you want to change it to six because some friends decided to join you at the last

minute. So you call the restaurant, ask them if it's possible to do that, and the customer service person puts you on hold. It takes a minute, but they finally come back and they say yes. Simple. You called someone, made a request, and you got a response, yes or no. Now let's say that

there was no customer service person and that it was up to you to figure out how many people have made reservations for the same time at this restaurant, how many tables do they have free at that time, what's their kitchen capacity, what's their wait staff capacity, all

to figure out whether you can add three more people to your reservation. That's a lot of unnecessary work on your part, work that you, the customer, have no expertise in and it means that the restaurant has to reveal a lot of data to you, maybe even private data about

who's eating there that night and who works there, etc. In this analogy, the restaurant is an application that provides a specific service or function, which is to feed you. You are an application that is trying to get fed with a group of friends. The customer service rep from the

restaurant is the restaurant's API, that is the interface through which you can communicate with the restaurant and make requests like changing the number on a reservation, and you can do that without having to dive into the messy details about how restaurant reservations work or anything like that.

For a more technical example now, think about Apple's weather app. Do we think that Apple decided to set up weather monitoring stations around the world? That's a really expensive endeavor, and if it was super critical to Apple's business model, then maybe sure, we could

we could see that happening. But there are already services out there that meticulously collect global weather data, services like weather.com. So if weather.com creates an API through which anybody can access their data, but only in the ways that weather.com allows, then Apple could just use that API to

populate their weather app. So how do APIs actually work? Let's use the example of web APIs, which are the type of APIs that deliver client requests and return responses via JSON or XML, usually over the internet. Each request and response cycle is an API call. A request typically consists of

a server endpoint URL and a request method, usually through HTTP or hypertext transfer protocol. The request method indicates the desired API action. The HTTP response contains a status code, a header, and a response body. The response body varies depending on the request, and it could be the server resource, a client

needs to access or any application-specific messages. One status code you might be familiar with when you've tried to visit a website that might be down or doesn't exist anymore is the error 404 code: URL not found. And that's it for request/response. To get more in-depth about APIs

and the various different types that exist, I encourage you to check out the Exponent article linked in the description below. Good luck with your interviews and thanks for watching. Thank you.

APIs Explained (in 4 Minutes)

Exponent

API는 애플리케이션 프로그래밍 인터페이스의 약자로, 서로 다른 애플리케이션이 통신하는 방식입니다.

애플리케이션은 특정 기능을 가진 소프트웨어이며, 인터페이스는 애플리케이션이 요청과 응답을 사용하여 통신하는 방식을 규정하는 프로토콜입니다.

비유: 저녁 식사 예약 변경 - 고객 서비스 담당자(API)를 사용하는 것이 레스토랑 수용 인원을 직접 파악하는 것보다 더 간단합니다.

레스토랑은 애플리케이션이고, 여러분은 애플리케이션이며, 고객 서비스 담당자는 API입니다.

예시: 예: Apple의 날씨 앱은 자체 날씨 모니터링 시스템을 만드는 대신 weather.com의 API를 사용합니다.

웹 API는 인터넷을 통해 JSON 또는 XML을 사용하며, 각 요청/응답은 API 호출입니다.

요청에는 서버 엔드포인트 URL과 요청 메서드(보통 HTTP)가 포함됩니다.  응답에는 상태 코드, 헤더, 응답 본문이 포함됩니다.

상태 코드의 예입니다: 오류 404(URL을 찾을 수 없음).

API와 그 유형에 대한 자세한 내용은 링크된 Exponent 문서에서 확인할 수 있습니다.