REST API 디자인 규칙 - 1장

1.1 Hello World Wild Web

• World Wild Web 이라는 비영리 소프트웨어 프로젝트를 시작한 팀 버너스리
  • 이후에 World Wide Web 이라는 명칭으로 변경됨.
  • W3는 전 세계에 있는 모든 도큐먼트에 접근하는 것을 목표한 광범위한 하이퍼미디어 정보검색의 시작
• 웹이 빠르게 성장하였지만, 핵심 프로토콜은 일관성 있게 구현되어 있지 않아서 확장이 어려운 상황이었음.

1.2 웹 아키텍쳐

• 목표는 웹이 지속적으로 확장하도록 하는 것임.
  1. 클라이언트/서버
     • 관심사의 분리.
     • 시스템 내에서 서버와 클라이언트 역할이 분명하게 나뉨.
  2. 균일한 인터페이스
     • 매체 간 인터페이스는 각 표준에 기반함.
       • 리소스 식별
         • 웹 상 서로 구별되는 어떤 개념, 식별자 (e.g., URI)
       • 표현을 통한 리소스 처리
         • 리소스 자체를 전송하는 것이 아닌 리소스의 표현을 전송.
       • 자기-서술적 메시지
         • 메시지가 자신을 어떻게 처리해야 할 지에 대한 정보를 포함하고 있어야 함. 즉 수신자가 이해하기 위한 모든 정보를 가지고 있어야 함.
       • 애플리케이션 상태 엔진으로서의 하이퍼미디어
  3. 계층 시스템
     • 웹의 일관된 인터페이스를 사용하면 클라이언트와 서버 사이에 네트워크 기반 매개체가 존재가 가능함.
  4. 캐시
     • 클라이언트 서버 사이의 네트워크 경로라면 어디에든 위치가 가능.
     • 웹의 전체적인 비용을 낮출 수 있음.
  5. 상태 없음
     • 웹 서버가 클라이언트 상태를 관리할 필요가 없음.
  6. 주문형 코드
     • 클라이언트는 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 하는지에 대한 Code를 서버가 제공하는 것을 의미함. 서버에서 제공되는 코드를 실행하기 때문에 보안이슈 가능성이 있음.

1.3 웹 표준

• 표준설계안 HTTP 1.1 스펙

1.4 REST

• Representational State Transfer (REST)

1.5 REST API

• REST API는 상호 연결된 리소스의 결합체 (리소스 집합 → 리소스 모델)

1.6 REST API 설계

여전히 우리는 다음과 같은 질문들에 대한 답을 찾아야 한다.

• URI 경로 path 세그먼트는 언제 복수로 써야 하는가?
• 리소스의 상태를 업데이트하려면, 어떤 메서드를 사용해야 하는가?
• CRUD 가 아닌 연산을 어떻게 URL에 매핑하는가?
• 특정한 시나리오에 가장 적합한 HTTP 응답은 무엇인가?
• 리소스 상태 표현의 버전은 어떻게 관리할 수 있는가?
• JSON에 포함된 하이퍼링크는 어떻게 구조화하는가?