Java RESTful API 개념 정리
오늘은 RESTful API에 대하여 정리해보려고 한다. RESTful API를 알기전에 REST와 RESTful의 차이를 알아야 한다. REST란, 분산시스템 설계를 위한 아키텍처 스타일이다. 즉, 제약 조건의 집합이라고 볼 수 있다. 그렇다면, RESTful은 무엇일까? RESTful은 제약조건의 집합 즉, 아키텍처 스타일, 아키텍처 원칙을 모두 만족하는 것을 의미한다.
RESTful API
RESTful API는 REST 아키텍처 원칙을 모두 만족하는 API라고 할 수 있다. 또한, 인터넷과 웹을 통해 나의 컴퓨터를 제어할때 어떻게하면 시행착오를 줄이고 더 좋은 API를 만들수 있는가에 대한 고민이다. RESTful API는 특정기술 지칭하는 것이 아니라, HTTP를 이용하여 기계들이 통신할때 HTTP가 가진 잠재력을 최대한 끌어낼 수 있는 모범사례라고 할 수 있다. HTTP메서드들을 본래 용도에 맞게 쓰자는 것도 중요한 목적
RESTful API의 구성요소
Resource(자원) 데이터들을 Resource라고 하고, REST API는 URI(정보를 식별하는 이름일뿐) 로 표현된다. Collection : Element 의 집합(복수형) Element: 콜렉션에서 하나하나의 데이터(단수형) URI를 가공하는 방법
Method(행위) 또한, 보통의 웹페이지간의 데이터 전송은 Post로 이루어지는 경우가 많다. REST는 HTTP메소드를 최대한 활용하는 아키텍처 스타일이다. 그렇기 때문에, REST는 HTTP메소드를 알맞은 곳에 사용하기를 원한다. 밑의 내용은 HTTP메소드의 원래의 기능을 알려준다.
Create -> post
Read -> get
Update -> put(전체), patch(부분)
Delete -> delete
Microsoft REST API Guidelines에서는 HEAD와 OPTIONS메소드도 알려주고 있다.
HEAD는 READ(GET) 응답을 위해 객체의 메타데이터를 리턴해주는 것이며, OPTION은 요청 정보를 얻는 것 즉, 도움말 정도로 볼 수 있을 것 같다.
여기서 put과 patch의 방식이 조금 혼동될 수 있지만, patch는 다른 데이터에 영향을 주지 않고 해당 데이터만 변한다면, put은 변경하려는 데이터를
제외하고는 삭제가 되는 차이를 예로 들 수 있다.(patch는 부분을 수정, put은 전체 수정)
REST 특징(제약 조건)
Server-Client(서버-클라이언트 구조)
REST서버는 API를 제공, Client는 사용자 인증이나 세션,로그인 정보등을 직접 관리하는 구조로 서버와 클라이언트 사이의 역할이 확실히 구분됨
그로인하여, 개발할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.
Stateless(무상태성)
작업을 위한 상태정보를 따로 저장하거나 관리하지 않는다. 따라서 들어오는 요청을 단순히 처리만 하면된다. 이로인하여 서비스의 자유도가 상승 서버의
불필요한 정보를 관리하지 않기 때문에 구현이 단순해진다.
Cacheable(캐시 처리 가능)
HTTP의 기존 웹표준을 그대로 이용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP의 캐싱기능을 적용할 수 있는 것이
다. (캐싱구현은 HTTP표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.)
Layered System(계층형 구조)
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워
크 기반의 중간매체를 사용할 수 있게한다.
Uniform Interface(인터페이스 일관성)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
Self-descriptiveness
REST API의 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다.