REST

REST 는 네트워크 위의 시스템을 어떤 모양으로 지을지 미리 정해 둔 결정입니다. 주고받는 것은 이름이 붙은 자원의 표현입니다. 반드시 받아들여야 하는 제약은 다섯 가지입니다. 코드온디맨드 하나는 선택으로 더 있습니다.

상세

REST(Representational State Transfer, 표현 상태 전이)는 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일입니다. Roy Fielding 의 박사논문 5장이 이 이름을 붙이고 내용을 정의했습니다. 논문은 REST 를 여러 네트워크 기반 아키텍처 스타일에서 끌어온 혼합 스타일이라고 적습니다. 거기에 균일한 커넥터 인터페이스를 정하는 제약을 더한 것이 REST 입니다.

자원은 이름을 붙일 수 있는 정보라면 무엇이든 될 수 있습니다. 논문은 문서와 이미지, "오늘 로스앤젤레스의 날씨" 처럼 시간에 따라 달라지는 서비스, 다른 자원들의 묶음, 사람 같은 실물 대상까지 자원의 예로 듭니다. 표현은 바이트의 나열에 그 바이트를 설명하는 메타데이터를 더한 것입니다. 받는 쪽이 손에 쥐는 것은 자원 자체가 아니라 이 표현입니다.

여섯 제약

균일 인터페이스의 네 갈래

논문은 REST 가 네 개의 인터페이스 제약으로 정의된다고 적습니다.

• 자원의 식별
• 표현을 통한 자원의 조작
• 자기 서술적인 메시지
• 애플리케이션 상태의 엔진으로서의 하이퍼미디어

대가

제약마다 내주는 것이 논문 안에 함께 적혀 있습니다.

무상태가 내주는 것

요청마다 같은 데이터를 되풀이해 보내게 됩니다. 논문은 이렇게 늘어난 반복 데이터가 네트워크 성능을 떨어뜨릴 수 있다고 적습니다. 그 데이터를 서버에 공유 맥락으로 남겨 둘 수 없어서 생기는 일입니다. 애플리케이션 상태를 클라이언트 쪽에 두는 것도 대가입니다. 일관된 동작에 대한 서버의 통제력이 줄어듭니다. 여러 클라이언트 판본이 의미를 올바로 구현했는지에 기대게 됩니다.

캐시가 내주는 것

캐시 안의 낡은 데이터가 서버에서 곧바로 받았을 데이터와 크게 다르면 신뢰성이 떨어질 수 있습니다.

균일 인터페이스가 내주는 것

논문은 균일 인터페이스가 효율을 깎는다고 적습니다. 정보가 애플리케이션의 필요에 맞춘 형태가 아니라 표준화된 형태로 전송되기 때문입니다.

계층 시스템이 내주는 것

계층 시스템의 주된 단점은 데이터 처리에 오버헤드와 지연을 더한다는 것입니다. 사용자가 체감하는 성능이 그만큼 줄어듭니다.

코드온디맨드가 내주는 것

가시성이 줄어듭니다. 논문이 이 제약 하나만 선택으로 남겨 둔 이유가 그것입니다.

이름의 출처

Roy Thomas Fielding 이 2000년 University of California, Irvine 의 박사논문에서 이 이름을 붙였습니다. 논문 제목은 "Architectural Styles and the Design of Network-based Software Architectures" 입니다. 학위는 Information and Computer Science 박사입니다. 지도교수는 Richard N. Taylor 입니다. 논문 5장이 REST 를 제시합니다. 글은

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

에 있습니다.

이름을 왜 그렇게 지었는지는 논문 6장 첫머리가 직접 밝힙니다. "Representational State Transfer" 라는 이름은 잘 설계된 웹 애플리케이션이 어떻게 행동하는지의 그림을 떠올리게 하려는 것이라고 적습니다. 웹 페이지들의 망이 가상 상태 기계입니다. 사용자는 링크를 골라 애플리케이션을 진행시킵니다. 링크를 고르는 것이 상태 전이입니다. 그 결과로 다음 상태를 나타내는 다음 페이지가 사용자에게 전송되어 화면에 그려집니다.

예시

GitHub 의 REST API(Application Programming Interface, 응용 프로그램 인터페이스) 가운데 저장소 조회 하나가 이 결정이 적용된 최소 형태 한 벌입니다.

GET /repos/{owner}/{repo}

curl -L \
  -X GET \
  https://api.github.com/repos/OWNER/REPO

응답은 상태 200 과 함께 자원의 표현을 돌려줍니다.

{
  "id": 1296269,
  "name": "Hello-World",
  "full_name": "octocat/Hello-World",
  "html_url": "https://github.com/octocat/Hello-World",
  "url": "https://api.github.com/repos/octocat/Hello-World",
  "clone_url": "https://github.com/octocat/Hello-World.git",
  "hooks_url": "https://api.github.com/repos/octocat/Hello-World/hooks"
}

URI(Uniform Resource Identifier, 통합 자원 식별자) 하나가 자원 하나를 가리킵니다. 돌아온 JSON(JavaScript Object Notation) 덩이는 그 자원 자체가 아니라 표현입니다. url · html_url · clone_url · hooks_url 은 이 자원에서 다음으로 갈 수 있는 곳을 가리키는 링크 필드입니다. 같은 응답에 archive_url · assignees_url 처럼 자원마다 갈 수 있는 곳을 가리키는 필드가 더 들어 있습니다.

sequenceDiagram
    participant 클라이언트
    participant 서버
    클라이언트->>서버: GET /repos/octocat/Hello-World
    서버-->>클라이언트: 상태 200 + 표현
    Note over 클라이언트: 표현 안의 hooks_url 이 다음 자원을 가리킨다

이견

REST 라는 이름을 무엇에 붙일 수 있는지에서 원전과 업계 용법이 갈립니다.

원전 쪽은 Fielding 본인입니다. 2008년 10월 20일 자기 사이트에 올린 글에서 그는 HTTP(HyperText Transfer Protocol) 기반 인터페이스면 무엇이든 REST API 라고 부르는 사람이 많아지는 것에 답답함을 느낀다고 적었습니다. 그날의 예로 든 SocialSite REST API 를 두고는 그것이 RPC(Remote Procedure Call, 원격 프로시저 호출)라고 적었습니다. 같은 글에서 그는 애플리케이션 상태의 엔진이 하이퍼텍스트로 구동되지 않는다면 그것은 RESTful 일 수 없고 REST API 일 수도 없다고 못 박았습니다.

통념 쪽은 스스로를 REST API 라 부르는 공식 문서들입니다. GitHub 의 "About the REST API" 문서는 REST API 를 자원별로 갈라 개별 문서화한 엔드포인트의 묶음으로 설명합니다. 하이퍼미디어와 애플리케이션 상태 전이는 이 문서에 나오지 않습니다.

어느 쪽이 이 이름의 주인인지는 여기서 판정하지 않습니다. 원전 저자와 그 이름을 쓰는 문서가 서로 다른 것을 가리킨다는 사실까지가 이 절의 자리입니다.

관련 항목

이것을 이루는 여섯 제약

클라이언트-서버 · 무상태 · 캐시 · 균일 인터페이스 · 계층 시스템 · 코드온디맨드

균일 인터페이스가 주고받는 대상

자원 · 표현 · 미디어 타입 · 메타데이터 · 메시지 · URI · 하이퍼미디어 · HATEOAS · 엔드포인트 · JSON

이 결정을 실무에서 구현하는 요소

네트워크 · HTTP · GET · 상태 코드 · Cache-Control · 멱등성 · RFC 9110 · 캐싱 · 세션

대가로 맞바꾸는 값

성능 · 지연 · 낡은 데이터

REST가 속하는 상위 분류

소프트웨어 아키텍처 · API · API 설계

REST와 맞세워지는 대립 개념

RPC · GraphQL

이견에서 맞서는 목소리

Roy Fielding · GitHub

이 이름을 있게 한 사람과 기관

Richard N. Taylor · University of California, Irvine