REST API

제가 아직도 Restful한 API에 대해 완전히 이해하고 있지는 않는듯 하여 여기저기 블로그 글 보고 이해하기 쉬운 내용들과 내가 이해한 내용을 기반으로 정리해놓으려고합니다.

 

REST

REST는 프로토콜이나 표준이 아닌 아키텍처 원칙 세트입니다.

API 개발자는 REST를 다양한 방식으로 구현할 수 있습니다.

 

REST구성요소

REST API는 자원(Resource), 행위(Verb), 표현(Representations)의 3가지로 구성되어있습니다.

구성 요소표현 방법의미

자원(Resource)	HTTP URI	URI는 정보의 자원을 표현해야한다.
행위(Verb)	HTTP Method	GET,POST,PUT,PATCH,DELETE와 같은 메서드
표현(Representations)	HTTP Message Pay Load	자원에 대한 행위는 HTTP Method로 표현

 

REST의 목표

• 구성요소 상호작용의 규모 확장성
• 인터페이스의 범용성
• 구성 요소의 독립적인 배포
• 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강호, 레거시 시스템을 인캡슐레이션

출처: METAFOR

HTTP Method 종류

Method용도

GET	데이터를 가져올때 (R) select문
POST	데이터를 입력할때 (C) insert문
PUT	데이터 전체를 수정할때 (잘 안씀) (U) update문
DELETE	데이터를 삭제할때 (D) delete문
PATCH	데이터를 일부수정 (U) update문
OPTIONS	요청을 체크
HEAD	데이터를 request message Header만 받아올때

 

RESTFUL API

RESTful API를 통해 요청이 수행될 때 RESTful API는 리소스 상태에 대한 표현을 요청자에게 전송합니다. 이 정보 또는 표현은 HTTP: JSON(Javascript Object Notation), HTML, XLT 또는 일반 텍스트를 통해 몇 가지 형식으로 전송됩니다. JSON은 그 이름에도 불구하고 사용 언어와 상관이 없을 뿐 아니라 인간과 머신이 모두 읽을 수 있기 때문에 가장 널리 사용됩니다.

위와같은 이유때문에 수업시간에도 JSON형식으로 주고받는것을 주로 배웠습니다.

 

RESTful API 충분조건

1) 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

2) 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

3) 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터

4) 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스. 여기에 필요한 것은 다음과 같습니다.

• 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.
• 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).
• 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
• 하이퍼미디어: 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.

5) 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.

6) 코드 온디맨드(선택 사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능.

이처럼 REST API는 따라야 할 기준이 있지만, 속도를 저하시키고 더 무겁게 만드는 XML 메시징, 빌트인 보안 및 트랜잭션 컴플라이언스처럼 특정 요구 사항이 있는 SOAP(Simple Object Access Protocol) 등의 규정된 프로토콜보다 사용하기 쉬운 것으로 간주됩니다.

출처: Red Hat

 

RESTful API의 가장 큰 장점은 직관적인 URI

수업중 교수님이 예를 들어주셨던걸 얘기해보자면

GET과 POST메서드를 써서 만들었을때는 기능별로 구별하기 위해서 URI가 길어집니다.

하지만, GET, POST, PATCH, PUT, DELETE와 같이 CRUD각각의 기능이 탑재된 메서드를 사용한다면 이것만으로도 하나의 구분값이 되어 URI를 똑같이 /user을 쓸 수 있습니다.
EX)

기능MethodURI=>기능MethodURI

회원가입	POST	/user	=>	회원가입	POST	/user
회원정보	GET	/user/userinfo	=>	회원정보	GET	/user
회원수정	POST	/user/modify	=>	회원수정	PATCH	/user
회원탈퇴	POST	/user/delete	=>	회원탈퇴	DELETE	/user