REST API
REST
REST(Representational State Transfer)란?
: 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
: 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.
자원이란 해당 소프트웨어가 관리하는 모든 것을 의미,
상태의 전달은 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다. 주로 JSON이나 XML 형식이다.
REST의 구체적인 개념은 HTTP URI을 통해 자원을 명시하고, HTTP Method(POST, GET, DELETE, PUT)를 통해 해당 자원에 대한 CRUD(CREATE, READ, UPDATE, DELETE) 오퍼레이션을 적용하는 것이라고 할 수 있다.
*CRUD란?
-Create : 생성(POST)
-Read : 조회(GET)
-Update : 수정(PUT)
-Delete : 삭제(DELETE)
-HEAD: header 정보 조회(HEAD)
를 뜻한다.
REST의 구성요소
1. 자원(Resource): URI
- 모든 자원에는 고유한 ID가 존재하게 되고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 HTTP URI로 구분하게 된다. (ex) /members/1
- Client는 URI을 이용하여 자원을 지정하고 해당 자원에 대한 조작을 Server에 요청한다.
*URI(Uniform Resource Identifier)
: 통합 자원 식별자라는 의미로 인터넷에 있는 자원을 나타내는 유일한 주소이다.
쉽게 생각하면 일종의 고유한 ID라고 보면 될 것 같다.
2. 행위(Verb): HTTP Method
- HTTP 프로토콜의 Method(GET, POST, PUT, DELETE)를 사용한다.
- Client는 HTTP Method(POST, GET, DELETE, PUT)를 이용하여 지정한 자원에 대한 조작을 요청한다.
3. 표현(Representation of Resource)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
REST의 6가지 원칙
1. Uniform Interface(인터페이스 일관성)
- 유니폼 인터페이스는 Client가 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 의미한다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
2. Stateless(무상태성)
- 상태 정보를 별도로 저장하고 관리하지 않는다는 것을 말한다.
- 세션 정보나 쿠키 정보를 별도로 저장하지 않아 서버는 들어오는 요청을 단순히 처리만 한다.
- 이런 특성으로 인해 서비스의 자유도가 높아지고, 서버에서 불필요한 정보를 관리하지 않기 때문에 구현이 단순해진다.
3. Caching(캐싱)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
4. Client-Server(클라이언트-서버)
- 클라이언트: 자원을 요청하는 곳 / 서버: 자원이 존재하는 곳
- 클라이언트 쪽과 서버 쪽이 분리 되어 있기 때문에 의존성이 줄어든다.
- REST Server: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
Client: 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다.
5. Hierarchical system(계층 시스템)
- Client는 REST API Server만 호출한다.
- REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
6. Self-descriptiveness (자체 표현 구조)
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다는 것이다.
- 예를 들어, REST API가 다음과 같을 때,
velog.io/@kjh107704/product/food/salad
이것만 보고도 salad가 food 이며 product에 속한 것을 단번에 알 수 있다.
REST의 장단점
장점
- Open API 를 제공하기 쉽다
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고 받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
단점
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에는 부적합하다.
- HTTP 통신 모델에 대해서만 지원한다.
REST API
REST API / RESTful API란?
: REST 기반의 규칙들을 지켜서 설계된 API를 REST API 혹은 RESTful API라고 한다.
- 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
*RESTful 이란?
: ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 표현하는 것이다.
이는 공식적으로 발표한 것이 아니며
REST의 기본 원칙을 성실히 지킨 웹 서비스를 보고 RESTful하다라고 말하는 것이다.
~ful 이라는 형용사형 어미를 붙여 ~한 API 라는 표현으로 사용된다.
RESTful하게 API를 디자인한다는 것은 무엇을 의미하는가.
1. 리소스(자원)와 행위를 명시적이고 직관적으로 분리한다.
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 한다.
- 행위는 HTTP Method로 표현하고, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)을 분명한 목적으로 사용한다.
2. Message는 Header와 Body를 명확하게 분리해서 사용한다.
- Entity에 대한 내용은 body에 담는다.
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입(파일 확장자) 등은 header에 담는다.
- header와 body는 http header와 http body로 나눌 수도 있고, http body에 들어가는 json 구조로 분리할 수도 있다.
3. API 버전을 관리한다.
- 환경은 항상 변하기 때문에 API의 signature 가 변경될 수도 있음에 유의하자.
- 특정 API 를 변경할 때는 반드시 하위호환성을 보장해야 한다.
4. 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- 브라우저는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는, json 으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일한다.
다른 말로 표현하자면 URI가 플랫폼 중립적이어야 한다.
출처
REST 서버, REST API란?
프로젝트를 진행하면서 REST 서버를 구축하고, REST API를 만들었다고 하긴 하는데 그게 정확히 뭐인지 모른 상태로 얼렁뚱땅 지나가다가 결심이 선 김에 공부해보면서 정리해본다.
velog.io
[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog
Step by step goes a long way.
gmlwjd9405.github.io