[데브코스] API와 REST API 제대로 이해하기

프론트엔드와 백엔드가 데이터를 주고받으며 작동하는 웹 환경에서 API는 빠질 수 없는 개념이다. API와 REST API에 대한 내용을 배우고 정리해보았다.

---

🌐 API

프로그램 간 상호작용을 도와주는 인터페이스

API는 서로 다른 소프트웨어가 서로 소통할 수 있게 해주는 통로 역할을 한다.

인터페이스란?

두 개체 사이를 중재하고 연결하는 매개

예를 틀어, 우리가 스마트폰을 사용할 때는 버튼이나 화면을 터치하면서 사용한다. 이렇게 사람-기기 사이를 연결해주는 인터페이스를 GUI라고 한다.

• GUI: 버튼, 아이콘 등 그래픽 요소로 제어하는 인터페이스
• CLI: 텍스트 명령어로 컴퓨터와 소통하는 인터페이스

👉 API는 개발자와 서버, 또는 프로그램과 프로그램 사이를 연결하는 인터페이스

 

백엔드 개발자와 API

백엔드 개발자는 비즈니스 로직을 처리하고, 이 로직을 외부에서 사용할 수 있도록 API로 만들어 제공한다.

---

🌍 REST API

API에도 여러 종류가 있는데, 웹 개발에서는 대부분 REST API를 사용한다.

 

REST란?

REprisentational State Transfer, HTTP 통신에서 자원을 효율적으로 주고 받기 위한 아키텍처 스타일

REST API를 만든다는 건, REST 규칙을 잘 지킨 API를 만든다는 뜻이다.

👉 REST API = HTTP 규약을 잘 지켜 만든 API

 

RESTful이란?

REST만큼 RESTful을 많이 들어봤을 것이다.

 

REST 원칙을 잘 지켜 구현한 API를 RESTful API라고 한다.
"RESTful"하다는 것은 설계가 깔끔하고, HTTP 프로토콜을 잘 활용하고 있음을 의미한다.

 

HTTP와 REST API

웹은 인터넷이라는 네트워크 위에서 작동한다. 인터넷에서 정보를 주고받으려면 반드시 규칙이 필요한데, 이 때 사용하는 규칙이 바로 HTTP(HyperText Transfer Protocol)이다.

 

REST API는 이 HTTP 위에서 작동하며, 데이터를 주고받기 위해 다음 요소들을 사용한다.

• 주소(URL): 어떤 리소스에 접근할 지 나타낸다.
• HTTP 메서드: 어떤 동작을 할지 나타낸다(GET, POST, PUT, DELETE 등)
• 데이터: 서버에 전달하거나, 서버로부터 받아올 실제 정보

 

REST API의 특징

REST API는 다음 특징을 가진다.

 

1. 클라이언트-서버 구조
사용자 인터페이스와 데이터 저장/처리를 명확히 분리한다.

 

2. 무상태성(Stateless)
서버는 요청 간의 상태를 저장하지 않는다.
모든 요청은 필요한 정보를 독립적으로 담고 있어야 한다.

 

3. 캐시 가능(Cachealbe)
응답은 캐시가 가능하게 설계할 수 있어 성능 향상에 도움이 된다.

 

4. 계층화 구조(Layered System)
클라이언트는 중간서버(프록시, 로드 밸런서)를 거쳐 요청해도 문제 없이 작동해야 한다.

 

5. 일관된 인터페이스(Uniform Interface)
REST의 핵심 원칙으로, 모든 리소스는 URI로 식별되고, HTTP 메서드로 행위를 표현한다.

 

URI

⭐ Uniform Resource Identifier, 인터넷 자원을 식별하기 위한 통합 자원 식별자

 

REST API 설계 규칙

REST API를 사용할 때는 다음과 같은 URL 설계 규칙을 지켜야 한다.

1. 소문자만 사용
2. 언더스코어(-) 대신 하이픈(-) 사용
3. 마지막에 슬래시(/)를 붙이지 않음
4. URL에 행위(동사)를 넣지 않음 - /getProducts ❌, /products ✅
5. 파일 확장자를 사용하지 않음
6. 리소스는 복수형으로 작성 - /product ❌, /products ✅

 

REST API 설계 예시

http://localhost:8888/전체 상품 조회
http://localhost:8888/상품 등록
http://localhost:8888/전체 상품 삭제

이처럼 동작하는 API를 설계해보자.

GET /products -> 전체 상품 조회
POST /product -> 상품 등록
DELETE /products -> 전체 상품 삭제

이렇게 설계할 수 있다.

 

또한 만약 하나의 상품만 조회하고 싶다면,

GET /products/1
GET /products/2

이렇게 ID 값을 URL에 포함시켜, 같은 API 엔드포인트 구조를 유지하면서도 유동적인 요청이 가능하다.

 

엔드포인트

⭐ 클라이언트가 서버에 요청을 보내는 URL 경로

---

API 개념을 만들고, API 설계 원칙을 배웠다. 동사를 쓰지 않는다는게 아직 익숙하지 않다. 여러가지 API 문서를 보고, API 설계에 대한 감을 잡아봐야겠다.