REST
-
Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식
-
네트워크로 연결된 어플리케이션의 설계를 안내하는 일련의 원칙
-
HTTP 통신에서 어떤 자원에 대한 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식을 제안
Rest 의 특징
-
Server - Client 구조
-자원이 있는 쪽이 Server, 요청하는 쪽이 Client
-Server와 Client를 구분지어서 서로 간의 의존성이 줄어듬
-
Stateless (무상태)
-Rest는 http 프로토콜로 통신하기에 http처럼 무상태성을 가짐
-Client는 요청을 보낼 때 필요한 모든 정보를 담아서 보냄
-Server는 Client의 정보를 따로 저장하지 않으며, 각 요청에 대해 개별적으로 처리
*이전 요청이 다음 요청 처리에 연관되지 않도록 처리 방식에 일관성을 부여
-
캐시 처리 기능
-웹 표준 HTTP 프로토콜을 사용하기 때문에 HTTP의 특징 중 하나인 캐싱 기능 적용 가능
-따라서 요청 과정에서 캐싱을 통해 대량 요청을 보다 효율적으로 처리 가능
-
Layered System (계층 구조)
-
Self-Descriptiveness (자체 표현)
-요청 메시지만 보고도 쉽게 이해가 가능하도록 자체 표현 구조로 되어 있음
Rest API
-
REST 의 설계규칙을 잘 지켜서 설계된 API
-
REST 의 기본 원칙을 잘 지키는 API를 Restful 하다고 표현
*보다 직관적이고 사용하기 쉬운 형태로 API 를 만드는 것이 Restful한 API -
다만 REST 에 대한 명확한 표준은 없음
Rest API 의 구성요소
-
Resource
서버는 고유한 ID를 가지는 Resource(주소값)를 가지고 있고, 클라이언트는 해당 Resource(주소값)을 통해 요청을 보냄
*Resource = 엔드포인트, URI
- Method
GET, POST, PUT, PATCH 등으로 서버에 요청을 보내는 방식을 의미
- Representation of Resource
클라이언트, 서버가 주고받는 데이터의 형태로 json, xml, text 등이 있음
*최근에는 대부분 json 형태를 많이 사용
Rest API 설계 규칙
핵심 규칙
-
URI 는 정보의 자원(resource)을 포함해야 함
-
자원에 대한 행위(Method)는 HTTP Method(GET, POST, PUT, PATCH, DELETE)로 표현
-
행위(Method)는 URI에 포함하지 않음
URI는 명사를 사용
- /getAllUsers, /deleteUser 같은 동사 사용 금지
슬래쉬(/) 로 계층 관계를 표현
URI 마지막은 슬래쉬(/) 로 표현하지 않음
밑줄( _ )을 사용하지 않고, 하이픈( - )을 사용
URI는 소문자로만 구성
HTTP 응답 상태 코드 사용
- 클라이언트는 요청에 대한 실패, 완료 등에 대한 피드백을 받아야 하기에 적절한 HTTP 상태코드 사용이 필요
파일확장자는 URI에 포함하지 않음
RESTful API
-
REST 의 설계규칙을 잘 따라서 설계된 API
-
기본 REST 의 규칙을 잘 따르는 시스템을 Restful 하다고 함
-
다만 REST 규칙 준수에 대한 명확한 표준은 존재하지 않음
