Rest, Rest API
안녕하세요 codesche입니다. 오늘은 API, Rest, Restful API 라는 키워드로 포스팅을 해보고자 합니다. 현재 프로젝트 진행중에 있다보니 예전만큼 포스팅하기가 쉽지 않네요... 이번 글을 계기로 잠시 잊고 있던 블로그에 대한 저의 마음이 되살아났으면 하는 바람입니다.
○ REST란?
REST는 Representational State Transfer의 줄임말로 자원의 이름으로 구분하여 해당 자원의 상태를 교환하는 것을 의미합니다. 아마 개발자 분들이라면 Rest API 또는 Rest라는 키워드를 많이 들어보셨을 겁니다. 더 깊게 들어가면 월드 와이드 웹(World Wide Web)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식입니다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었습니다. 이 REST의 원리를 따르는 시스템이 종종 Restful이란 용어로 지칭되기도 합니다. Restful API라고 들어보셨나요? 흔히 스프링에서 Controller를 구성할 때 GET, POST, PUT, DELETE 기능을 많이 사용합니다. Restful API는 HTTP Request를 이용해 데이터를 GET, POST, PUT, DELETE할 수 있는 API를 의미합니다.
REST는 서버와 클라이언트의 통신 방식 중의 하나입니다. HTTP URI(Uniform Resource Identifier)를 통해 자원을 명시하고 HTTP Method를 통해 자원을 교환하는 것을 의미합니다.
○ REST 특징 (6가지 제약 조건)
1. Server-Client 구조
자원이 있는 쪽이 Server, 요청하는 쪽이 Client 입니다.
클라이언트와 서버가 독립적으로 분리가 되어 있어야 합니다.
2. Stateless
요청 간에 클라이언트 정보가 서버에 저장되지 않습니다.
서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.
Stateless는 서버가 클라이언트의 세션 상태 및 세션 정보를 저장하지 않는 네트워크 프로토콜입니다.
아마 로그인/회원가입 개발을 해보신 분이라면 세션에 대한 개념은 알고 계실 겁니다. Stateless를 한글로 번역하면 무상태 프로토콜이라고 하는데 이는 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜을 의미합니다. 이와 반대되는 개념으로 Stateful이 있는데 Stateful은 상태정보를 저장하는 형태이며 세션 상태에 따라 서버의 응답이 달라집니다.
3. Cacheable (캐시 가능한 응답 - 나중에 검색하고 사용하기 위해 저장하여 새 요청을 서버에 저장)
HTTP 프로토콜을 그대로 사용하기 때문에 HTTP의 특징인 캐싱 기능을 적용하여 대량의 요청을 효율적으로 처리하기 위해 캐시를 사용합니다.
4. 계층화 (Layered System)
클라이언트는 서버의 구성과 상관없이 REST API 서버로 요청하며 서버는 다중 계층으로 구성될 수 있습니다.
(로드밸런싱, 보안 요소, 캐시 등)
5. Code on Demend (Optional)
요청을 받으면 서버에서 클라이언트로 코드 또는 스크립트(로직)을 전달하여 클라이언트 기능을 확장합니다. 서버가 네트워크를 통해 클라이언트에 전달한 자바스크립트 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 하며 이것은 사전 구현에 필요한 기능의 수를 줄임으로서 클라이언트를 단순화할 수 있습니다.
예를 들어 정적인 데이터를 xml 또는 json에 담아서 클라이언트로 보내고 클라이언트가 이것을 가공합니다. code on demand는 클라이언트에 보내는 데이터를 바로 실행 가능한 코드를 보내 이것을 클라이언트에서 실행하는 것을 말합니다.
6. 인터페이스 일관성 (Uniform Interface)
정보가 표준 형식으로 전송되기 위해 구성 요소간에 통합 인터페이스를 제공해줍니다. HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하게끔 설계합니다.
○ REST의 장점
1. HTTP 표준 프로토콜을 사용하는 모든 플랫폼에서 호환 가능하며, 여러 프로그래밍 언어로 구현할 수 있습니다.
2. 서버와 클라이언트의 역할을 명확하게 분리합니다.
3. 여러 서비스 설계에서 생길 수 있는 문제를 최소화합니다.
4. REST기반으로 시스템을 분산하여 확장성과 재사용성이 있습니다.
○ REST API 설계 규칙
1. 웹 기반의 REST API를 설계할 경우 URI를 통해 자원을 표현해야 합니다.
ex) https://codesche.io/member/1234
Resource : member
Resource id : 1234
2. 자원에 대한 조작은 HTTP Method(CRUD)를 통해 표현해야 합니다.
URI에 행위가 들어가면 안 되며 HEADER를 통해 CRUD를 표현하여 동작을 요청해야 합니다.
ex)
❌ POST http://codesche-tools.tistory.com/users/post/1
⭕ PUT http://codesche-tools.tistory.com/users/1
3. 메시지를 통한 리소스 조작
HEADER를 통해 'content-type'을 지정하여 데이터를 전달합니다.
대표적인 형식으로는 HTML, XML, JSON, TEXT가 있습니다.
4. URI에는 소문자를 사용합니다.
Resource의 이름이나 URI가 길어질경우 하이픈(-)을 사용하여 가독성을 높입니다.
ex) http://codesche-tool.com/users/post-comments
5. 언더바(_)를 사용하지 않습니다.
ex)
❌ http://codesche.tistory.com/users/post_comments
6. 파일 확장자를 표현하지 않습니다.
ex)
❌ http://codesche.tistory.com/users/photo.jpg
⭕ GET http://codesche.tistory.com/users/photo
7. 슬래시를 포함하지 않습니다.
ex)
❌ http://codesche.tistory.com/users/
⭕ http://codesche.tistory.com/users