Week 11. RESTful API의 개념과 주요 제약 조건

RESTful API는 웹 서비스 개발에서 널리 사용되는 아키텍처 스타일인 REST(Representational State Transfer)를 따르는 API를 말합니다. REST는 웹의 기존 기술과 HTTP 프로토콜을 활용하여 시스템 간의 상호 운용성을 높입니다. 

RESTful API의 개념

• 자원(Resource)의 개념화
  • 모든 것은 자원으로 취급되며, 각 자원은 고유한 URI로 식별됩니다.
• HTTP 프로토콜의 활용
  • CRUD 기능을 HTTP 메서드로 매핑하여 사용합니다.
    • GET: 자원의 조회
    • POST: 자원의 생성
    • PATCH, PUT: 자원의 수정
    • DELETE: 자원의 삭제
• 다양한 표현(Representation) 형식 지원
  • JSON, XML 등 다양한 형식으로 자원의 상태를 주고받을 수 있습니다.
• 클라이언트-서버 구조
  • 클라이언트와 서버의 역할을 분리하여 개발의 독립성과 확장성을 높입니다.

REST의 주요 제약 조건

1. 클라이언트-서버 구조 (Client-Server)
   • API를 통해 정보를 교환하는 주체는 클라이언트와 서버 구조를 가져야 한다.
   • 클라이언트와 서버의 분리를 통해 서로 의존하지 않는 구조를 가져야 한다. (관심사의 분리)
2. 무상태성 (Stateless)
   • 서버는 클라이언트의 상태를 저장하지 않고, 각 요청을 독립적으로 처리해야 한다.
   • 클라이언트의 각 리퀘스트는 서버가 리퀘스트를 이해하는 데에 필요한 모든 정보를 포함해야 한다.
3. 캐시 가능 (Cacheable)
   • 데이터 복사본을 임시 저장 위치에 저장하여 보다 빠르게 액세스할 수 있도록 하는 프로세스인 캐싱을 통해 네트워크 효율성을 높인다.
   • 리퀘스트에 대한 리스폰스에 캐시 가능 및 불가능 여부가 들어 있어야 한다.
4. 일관된 인터페이스 (Uniform Interface)
   • 일관된 방식으로 자원에 접근하고 조작할 수 있어야 합니다.
   • 이는 다음의 네 가지 제약으로 세분화됩니다.
     • 자원의 식별 (Identification of Resources)
       • 각 자원은 고유한 URI로 식별됩니다.
     • 메시지를 통한 자원의 조작 (Manipulation of Resources through Representations)
       • 클라이언트는 자원의 표현을 변경하여 상태를 변경할 수 있습니다.
     • 자체 표현적 메시지 (Self-descriptive Messages)
       • 메시지는 추가적인 상태 정보를 포함하여 독립적으로 이해될 수 있어야 합니다.
     • 하이퍼미디어에 의한 애플리케이션 상태 엔진 (HATEOAS)
       • 클라이언트는 서버가 제공하는 링크를 따라 애플리케이션의 상태를 전이합니다.
5. 계층화 시스템 (Layered System)
   • 시스템은 여러 계층으로 구성될 수 있으며, 각 계층은 다른 계층의 기능에 영향을 주지 않고 독립적으로 동작합니다.
   • 로드 밸런싱, 캐시, 보안 계층 등을 투명하게 추가할 수 있습니다
6. 코드 온 디맨드 (Code on Demand) - 선택적
   • 서버에서 보낸 코드를 클라이언트에서 실행할 수 있어야 한다.(e.g. Javascript)
   • 선택적 제약 조건이며 지켜지 않아도 REST에는 문제가 없다.

결론

RESTful API는 그 제약 조건을 준수함으로써 시스템의 확장성, 유연성, 성능을 향상시킬 수 있습니다. REST의 철학은 단순함과 표준의 활용에 있으며, 이를 통해 개발자는 효율적이고 유지 보수가 용이한 API를 설계할 수 있습니다.