RESTful API

 

 

 

 

RESTful API란?

API

• Application Programming Interface의 약어
• 두 애플리케이션이 서로 통신하는 방법을 정의

RESTful

• REST 아키텍처 스타일로 요청과 응답을 하는 API

---

REST 아키텍처의 탄생 배경

HTTP 프로토콜

• REST의 기반이 된다.
• 클라이언트와 서버 간의 데이터를 주고받기 위해 사용되는 표준

 

 

HTTP 프로토콜이 표준화되어있긴 하지만 이를 어떻게 구현해야할지 그 방식에 대해서는 유연하기 때문에 개발자마다 구현 방식이 달라지게 된다. → 내용이 복잡하고 유지보수가 어렵게 된다.

 

→ 웹(HTTP)의 장점을 최대한 활용할 수 있는 REST 아키텍쳐를 만들자

 

---

REST란?

REpresentational State Trasfer(표현 상태 전달)의 약자

= 자원을 이름(표현)으로 구분하여 자원의 상태(정보)를 전달한다.

 

자원: URI

모든 URI는 자원으로 표현한다.

• 첫 번째 사진(X) 
  • 이해가 어렵지는 않지만 REST의 방식에 어긋난다.
• 두 번째 사진
  • URI는 자원(명사)로 표현되어야 한다.
  • 자원에 대한 조작은 HTTP METHOD로 표현해야 한다.

 

 

1. 슬래쉬 구분자를 통해 자원 간의 계층 관계를 나타낸다.

 

 

2. 언더바 대신 하이픈을 사용한다.

컴퓨터 폰트에 따라서 언더바를 지원하지 않는 경우도 있기 때문이다.

 

3. 소문자 사용

대문자를 사용할 경우, 일관성이 떨어질 수 있기 떄문이다.

 

 

4. URI의 마지막에는 슬래시를 포함하지 않는다.

마지막 슬래쉬는 아무 의미없고 혼란만 야기할 수 있기 때문이다.

 

 

 

행위(or 상태): HTTP METHOD

• 자원에 대한 모든 행위는 HTTP METHOD로 표현한다.
• GET, POST, PUT, PATCH, DELETE 등

 

/shopping/carts/1

 

1. GET 

• 리소스를 조회하는 역할
• 1번 데이터를 조회하는 역할을 한다.

2. DELETE

• 1번 상품을 삭제하는 역할

3. PUSH

• 리소스의 업데이트하는 메소드
• 빈 정보는 null값으로 들어간다.

4. PATCH

• 리소스를 업데이트하는 메소드
• 빈 정보는 기존 데이터로 유지가 된다.

5. POST

• 리소스를 생성하는 메소드
• body에 생성할 리소스의 정보를 담아서 post메서드를 이용하면 리소스가 생성되게 한다.

 

 

표현: 요청 HEADER

• 리소스의 응답 타입은 요청 HEADER로 나타낸다.
• Accept 헤더 사용하여 응답 타입 지정

 

 

---

REST API 설계 원칙

1. Uniform Interface
2. Stateless (무상태성)
3. Cacheable (캐시 가능)
4. Client-Server
5. Layered System (계층형 구조)

지금까지 살펴본 것은 Uniform Interface에 포함되는 원칙들이다. 1번을 제외하고 나머지 원칙들은 인터넷을 사용함으로써 자연스럽게 제약이 지켜지기 때문에 API를 설계하는 개발자는 Unifrom Interface의 원칙을 지키기 위해 노력하면 된다.