[정리] REST API

728x90

REST는 API에 대한 조건을 부과하는 소프트웨어 아키텍처 스타일이다.

REST는 REpresentational state Transfer의 약자로 직역하면 "대표 상태 전송" 이다.

서버에서 클라이언트가 요청의 상태를 파악할 수 있게 하는게 핵심이다.

REST는 아키텍쳐 스타일이다.

스타일은 제약조건의 집합인데 REST에서도 제약조건들이 몇가지 있다.

그중 uniform interface에 대해서 말하려고 한다.

1. Identification of resources

REST는 기본적으로 리소스를 기반으로 URI를 설계한다.

예를 들면 유저의 정보를 받아오는 URI를 설계한다고 한다면

혼자서 개발하는 경우 어떤 URI를 쓰든 상관없다.

/1
/user
/data

위 3개 중 아무 URI로 해도 나만 알아보면 되는거기 때문에 상관이 없다.

하지만 팀원과 같이 하는경우 URI를 통해 어떤 데이터가 오가는지 추측할수 있게 설계해야 한다.

/user

위와 같이 user라는 리소스를 기반으로 URI를 설계할 경우 이건 user의 정보를 어떻게 하겠구나~ 라는 추측을 할 수 있다.

삭제, 수정 등을 한다는 것을 요청에 포함한채로 전송하여 해당 작업을 수행하는 것이다.

Http Method를 사용해 GET, POST, PUT, DELETE 등으로 요청을 보내는 것과 같다.

메시지는 스스로를 설명해야 한다는 규칙이다.

예를 들어 응답 메시지가 다음과 같다.

[ { "name" : "remove" , "path" : "/a/b/c" }]

이 메시지만 본다면 name이 무엇이고 path가 무엇인지, 대괄호, 중괄호의 의미는 무엇인지 알 수 없다.

그래서 메시지 스스로 설명을 하기 위해 헤더에 메시지에 대한 설명을 써준다.

Content-Type : application/json-patch+json
[{ "name" : "remove" , "path" : "/a/b/c" }]

content-type을 통해 이 데이터들이 어떠한 형식인지 알 수 있다.

하지만 아직 name이 무엇인지, path가 무엇인지를 설명하지 못한다.

이를 위해 Link 헤더를 사용할 수 있다.

name과 path가 무엇인지 정의한 명세를 작성후 Link 헤더에 profile relation으로 링크하는것이다.

Content-Type : application/json-patch+json
Link : <https://www.명세링크.com>; rel="profile"
[{ "name" : "remove" , "path" : "/a/b/c" }]

이러면 해당 메시지는 스스로 어떤 메시지인지 설명할 수 있게 된다.

애플리케이션의 상태는 하이퍼링크를 이용해 전이되어야 한다는 조건이다.

예를 들면 게시판에 입장했다.

게시판에서 하나의 글에 대한 세부정보를 보려면 a태그나 링크를 이동하는 처리를 통해 링크를 이동해야한다.

또, 새로운 글을 쓰려고 한다면 글을 쓰는 링크로 이동하고 글이 작성된다면 작성한 글의 링크로 이동하는 버튼이 있어야 한다.

이러한 링크이동을 위해 헤더에 Link를 이용할 수 있다.

Link : <https://www.~~~.com>; rel="collection"

참고

728x90