REST란 무엇이며 그 주요 제약(constraint)은 무엇인가?

Question

IT Interview Practice · Accepted Answer

**REST**(Representational State Transfer)는 Roy Fielding이 정의한, 네트워크 애플리케이션을 위한 **아키텍처 스타일(architectural style)**이다. 프로토콜이나 표준이 아니라 — 따르면 API를 확장 가능하고, 캐시 가능하며, 진화하기 쉽게 만드는 **제약(constraints)**의 집합이다. "RESTful" API는 모든 것을 URI로 식별되는 **리소스**(user, order, product)로 모델링하고, 표준 HTTP method로 그것들을 조작한다.

## 핵심 제약

- **Client–server** — UI(client)와 데이터 저장(server)을 분리해 각각 독립적으로 진화하게 한다.
- **Stateless** — 모든 request는 처리에 필요한 모든 정보를 담는다. server는 request 사이에 **client의 session 상태를 전혀 유지하지 않는다**. 어떤 server든 어떤 request든 처리할 수 있어 수평 확장이 쉬워진다.
- **Cacheable** — response는 캐시 가능 여부를 선언해, client와 proxy가 그것을 재사용할 수 있게 한다.
- **Uniform interface** — 규정적인 제약: 리소스는 URI로 식별되고, representation(보통 JSON)으로 조작되며, 메시지는 자기 서술적이고, hypermedia 링크가 client를 안내한다.
- **Layered system** — proxy, gateway, load balancer가 client와 server 사이에 투명하게 자리할 수 있다.
- **Code-on-demand**(선택) — server가 실행 가능한 코드(예: JavaScript)를 보낼 수 있다.

## 리소스 지향 request

```http
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
```

```http
HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 42, "name": "Ann", "email": "ann@example.com" }
```

URI `/users/42`는 리소스의 이름을 짓고, `GET`은 동작이며, JSON은 representation이다. 그 조합 — path에는 명사, 동사는 HTTP method — 이 REST의 핵심이다.

## 왜 중요한가

REST는 웹 API의 지배적인 스타일이므로, 면접관은 이 질문으로 당신이 그것을 철자할 줄 아는지가 아니라 *왜* 그것이 작동하는지 이해하는지를 확인한다. 실무에서 가장 중요한 두 제약은 **statelessness**(각 request가 자기 완결적이라, 몇 대의 server든 load balancer 뒤에 두고 sticky session 없이 수평 확장할 수 있음)와 **uniform interface**(예측 가능한 리소스 지향 URL에 표준 HTTP method와 status code를 더한 것으로, client가 엔드포인트마다 별도 로직이 필요 없음)다. 좋은 답은 제약을 구체적 이점과 연결한다 — statelessness는 확장을 가능케 하고, cacheability는 부하를 줄이며, layered system은 CDN과 gateway를 끼워 넣게 한다 — 그리고 대부분의 "REST" API가 완전한 RESTful이라기보다 실용적이라는 점(HATEOAS를 구현하는 곳은 드물다)을 언급한다. 이 제약들을 이해하는 것은 status code 선택부터 versioning까지 다른 모든 REST 설계 결정의 토대다.

핵심 제약

리소스 지향 request

왜 중요한가

관련 질문