RESTFUL API - 이응준 님의 '그런 REST API로 괜찮은가' 정리

REpresentational State Transfer
- REST: a way of providing interoperability between computer systems on the internet.
- 인터넷 상의 컴퓨터 시스템간 상호 운용성(interoperability)을 제공하는 방법중의 하나. www와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식.
- 즉 REST API는 Restful한 API = REST 아키텍처의 형식을 지켜서 구현한 API다.
WEB
- WEB(1991)
  - 어떻게 인터넷에서 정보를 공유할까? 표현형식: HTML, 식별자: URI, 전송방법: HTTP 프로토콜 까지 구현은 했는데
- HTTP/1.0 (1994-1996)
  - Roy T. Fielding이 Web의 구조를 변형되지 않게하고 어떻게 HTTP 성능을 개선할까 고민하는 과정에서 HTTP Object Model 제안
- REST(2000)
  - Roy T. Fielding이 HTTP Object Model 제안 2년 후에 REST를 박사논문으로 발표
  - REST vs SOAP 에서 단순하고, 규칙이 적고 쉽다는 장점으로 REST가 살아남음.
REST 6가지 조건
- client - server
- stateless
- cache
- uniform interface
- layered system
- code on demand(서버에서 클라이언트로 코드를 통해 데이터 전송 가능, javascript)
Uniform Interface의 제약조건(특히 꼭 지켜야 하는 두 가지)
- identification of resources
- manipulation of resources through representations
- self-descriptive messages
- hypermedia as the engine of application state (HATEOAS)

왜 Uniform Interface?
- 독립적 진화
  - 서버와 클라이언트가 각각 독립적으로 진화한다.
  - 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  - 위에서 언급했던 REST를 만들게 된 계기: "How do I improve HTTP without breaking the Web."
- 상호운용성(interoperability)에 대한 집착. 아래 예시
  - Referer 오타지만 안고침
  - charset 잘못지은 이름이지만 안 고침
  - HTTP/0.9 아직도 지원함 (크롬, 파이어폭스)
REST가 웹의 독립적 진화에 도움을 주었나
- HTTP에 지속적으로 영향을 줌
- Host 헤더 추가
- 길이 제한을 다루는 방법이 명시(414 URI Too long 등)
- URI에서 리소스의 정의가 추상적으로 변경됨: "식별하고자 하는 무언가"
- 기타 HTTP와 URI에 많은 영향을 줌
- HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
- Reminder: Roy T. Fielding이 HTTP와 URI 명세의 저자 중 한명
그럼 REST는 성공했는가
- REST는 웹의 독립적 진화를 위해 만들어짐
- 웹은 독립적으로 진화
- 그러므로 성공
그럼 REST API는 ?
- REST API는 REST 아키텍처 스타일을 따라야 한다.
- 오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍처 스타일을 따르지 않는다.

<참고자료>

[WEEK 16] 나만의 무기 - TIL (0)	2022.07.18
[WEEK 15] 나만의 무기 - TIL (0)	2022.07.15
[WEEK 13] 정글끝까지 - PintOS 4. File System (0)	2022.06.30
[WEEK 11 - 12] 정글끝까지 - PintOS 3. Virtual Memory (0)	2022.06.30
[WEEK 9 - 10] 정글끝까지 - PintOS 2. USER PROGRAMS (0)	2022.06.06

개발 블로그