REST API란?

"Representational State Transfer" API의 약자로, 웹 서비스의 설계를 위한 아키텍처 스타일입니다. REST는 주로 HTTP를 통해 통신하며, 이를 통해 클라이언트와 서버 간의 상호 작용을 정의합니다. HTTP URI를 통해 자원을 명시하고 HTTP Method를 통해 자원을 교환합니다.

REST API 원칙

• 무상태성 (Stateless): 각 요청은 독립적이며, 서버는 이전 요청의 상태를 기억하지 않습니다. 모든 필요한 상태 정보는 요청에 포함되어야 합니다.
• 클라이언트-서버 구조 (Client-Server Architecture): 클라이언트와 서버는 서로 독립적으로 개발되고 운영됩니다. 클라이언트는 사용자 인터페이스를 관리하고, 서버는 데이터 저장 및 로직을 처리합니다.
• 캐시 가능성 (Cacheable): HTTP 응답은 캐시 가능해야 하며, 클라이언트는 응답을 캐시하여 서버의 부하를 줄일 수 있습니다.
• 계층형 시스템 (Layered System): 클라이언트는 중간 서버(프록시, 게이트웨이 등)를 통해 서버와 상호 작용할 수 있습니다. 이러한 계층 구조는 확장성과 보안성을 향상시킵니다.
• 통합된 인터페이스 (Uniform Interface): 자원(Resource)은 URI(Uniform Resource Identifier)로 식별되고, 고정된 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 조작됩니다.

REST API 주요 개념

• 자원(Resource): REST에서 모든 것은 자원으로 간주됩니다. 예를 들어, 사용자, 게시물, 댓글 등이 자원입니다.
• URI: 각 자원은 고유한 URI로 식별됩니다. 예를 들어, https://api.example.com/users/1은 ID가 1인 사용자를 가리킵니다.
• HTTP 메서드: REST API는 CRUD 작업을 HTTP 메서드로 매핑합니다.
  • GET: 자원의 조회
  • POST: 자원의 생성
  • PUT: 자원의 수정
  • DELETE: 자원의 삭제
• 헤더(Header)와 본문(Body): 요청과 응답은 추가 정보를 전달하기 위해 헤더와 본문을 사용할 수 있습니다. 예를 들어, 콘텐츠 타입, 인증 정보 등이 포함될 수 있습니다.

REST API 설계 규칙

• 웹 기반의 REST API를 설계할 경우에는 URI를 통해 자원을 표현해야 합니다.
• 자원에 대한 조작은 HTTP Method(CRUD)를 통해 표현해야 합니다.
  -> URI에 행위가 들어가면 안되고 HEADER를 통해 CRUD를 표현하여 동작을 요청해야 합니다.
• 메세지를 통한 리소스를 조작해야 합니다.
  -> HEADER를 통해 content-type을 지정하여 데이터를 전달합니다. 대표적 형식으로는 HTML, XML, JSON, TEXT가 있습니다.
• URI에는 소문자를 사용하고 Resource의 이름이나 URI가 길어질 경우 하이픈(-)을 통해 가독성을 높일 수 있습니다.
• 언더바(_)는 사용하지 않고 파일 확장자를 표현하지 않습니다.