Spring Boot 기반 REST API 개발

REST API

카테고리 : Spring Boot 기반 REST API 개발 tag #Restapi

REST API

API( Application Programming Interface )

  • 어떠한 응용 프로그램에서 데이터를 주고 받기 위한 방법을 의미한다.
  • 어떤 특정 사이트에서 데이터을 공유할 경우 어떠한 방식으로 정보를 요청해야 하는지, 그리고 어떤한 데이터를 제공 받을 수 있을지에 대한 규격을 API라고 한다.

REST( REpresentational State Transfer )

  • HTTP/1.0과 1.1의 스펙 작성에 참여 하였고 아파치 HTTP 서버 프로젝트의 공동 설립자인 로이 필딩(Roy Fielding)의 2000년도 논문에서 처음 소개 됬었다.
  • 발표 당시의 웹이 HTTP의 설계의 우수성을 제대로 사용하지 못하고 있는 상황을 보고, 웹의 장점을 최대한 활용할 수 있는 아키텍쳐로서 REST를 소개 하였다.
  • REST는 HTTP 프로토콜의 의도에 맞게 디자인 하도록 유도하고 있다.

REST( REpresentational State Transfer )란 무엇?

  • REST는 분산 시스템 설계를 위한 아키텍쳐 스타일이다.
  • 아키텍쳐 스타일이라는 것은 제약 조건의 집합이라고 보면 된다.

RESTful은 무엇?

  • RESTful은 위의 제약 조건의 집합 ( 아키텍쳐 원칙 )을 모두 만족하는 것을 의미한다.
  • REST라는 아키텍쳐 스타일이 있고, RESTful API라는 말은 REST 아키텍쳐 원칙을 모두 만족하는 API라는 뜻이다.

REST가 필요한 이유는 무엇?

  1. 분산시스템을 위해서 필요
    • 거대한 어플리케이션 모듈, 기능별로 분리하기 쉬워졌다. RESTful API를 서비스 하면 어떤 다른 모듈 또는 어플리케이션들이라도 RESTful API를 통해서 상호간에 통신을 할 수 있기 때문이다.
  2. Web 브라우저 이외의 클라언트를 위해서 필요
    • 웹페이지를 위한 HTML 및 이미지 등을 보내던 것과는 다르게, 데이터만 보내면 여러 클라이언트에서 해당 데이터를 주고 받기 때문에 자유롭고 부담없이 데이터를 이용할 수 있다.
    • 서버도 요청한 데이터를 보내기 만 하므로 가벼워지고 유지 보수성도 좋아질 수 있다.

REST의 구성요소?

  • HTTP URL( 자원 ) + HTTP Method( 행위 )
  • URL는 정보의 자원을 표시해야 한다. - Resource명은 동사 보다는 명사를 사용 한다.
  • 자원에 대한 행위는 HTTP Method( GET, POST, PUT, DELETE )로 표현한다.

REST의 제약조건

  1. Client / Server 구조 : Server는 자원을 가지고 있고, Client는 자원을 요청한다.
  2. Stateless ( 무상태 ) : 서버에서 클라이언트의 세션과 쿠키와 같은 context를 저장하지 않으므로 구현이 단순하다.
  3. Cache ( 캐시 처리 가능 ) : HTTP가 가진 캐시 처리 기능을 그대로 적용 할 수 있다.
  4. Layered System ( 계층화 ) : REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있다.
  5. Uniform Interface ( 인터페이스 일관성 ) : 자원은 유일하게 식별 가능해야 하고 , HTTP Method로 표현을 담아야 하며, 메시지는 스스로 설명(self-descriptive) 해야 하고, 하이퍼링크를 통해서 어플리케이션의 상태가 전이(HATEOAS) 되어야 한다.

Uniform Interface의 제약조건

  1. Identification of Resources : 리소스가 URI로 식별 된다.
  2. Manipulation of Resources through Representations : 리소스를 삭제하거나 수정할 때 HTTP 메시지에 이러한 표현을 담아서 전송해야 한다.
  3. Self-Descriptive Messages
    1. 메시지 스스로 메시지에 대한 설명이 가능해야 한다.
    2. 서버가 변해서 메시지가 변해도 클라이언트는 그 메시지를 보고 해석이 가능하다.
    3. 확장 가능한 커뮤니케이션
    4. 해결 방법
      1. 미디어 타입을 정의하고 IANA에 등록하고 그 미디어 타입을 리소스를 리턴 할 때 Content-Type으로 사용한다.
      2. profile 링크 헤더를 추가 한다.
  4. Hypermedia As The Engine of Application State(HATEOAS)
    1. 링크에 사용 가능한 URL을 리소스로 전달하여 client가 참고하여 사용할 수 있도록 하는 것
    2. 하이퍼미디어(링크)를 통해 애플리케이션 상태 변화가 가능해야 한다.
    3. 해결 방법
      1. 데이터에 링크를 제공한다. (HAL)
      2. 링크 헤더나 Location을 제공한다.

HAL

  • HAL의 최초 제안자인 Mike Kelly의 HAL에 대한 정의

    HAL은 API의 리소스들 사이에 쉽고 일관적인 하이퍼링크를 제공한느 방식이다. API 설계 시 HAL을 도입하면 API간에 쉽게 검색이 가능하다. 따라서 해당 API를 사용하는 다른 개발자들에게 좀 더 나은 개발 경험을 제공한다.

      즉, HAL을 API Reponse 메시지에 적용하면 그 메시지가 JSON 포맷이건 XML 포맷이건 API를 쉽게 찾을 수 있는 메타 정보들을 포함시킬 수 있다는 것이다.
  특히 Mike Kelly는 이 HAL을 적용하는데 있어서, 이를 위해서 불필요한 추가 작업을 하기 보다는 자동화된 방식을 적용하는 것을 선호한다.

© 2020. All rights reserved.

SIKSIK