Representational State Transfer API
REST의 특징을 기반으로 API를 제공하는 것
✔️ 공공데이터, 구글 맵, 마이크로 서비스 등이 대부분 REST API를 통해 제공함.
✔️ HTTP 표준을 기반으로 구현하기 때문에 HTTP를 지원하는 프로그램 언어를 사용하여 클라이언트와 서버를 구현할 수 있다.
자원(Resource) - URI
행위(Verb) - HTTP METHOD
표현(Representations)
URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말함
작업을 위한 상태 정보를 따로 저장하고 관리하지 않음.
세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됨. 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않아서 구현이 단순해짐
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹 표준을 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있음. 따라서 HTTP가 가진 캐싱 기능을 적용할 수 있다.
REST API 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다는 점
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간의 의존성이 줄어들게 됨
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조 상의 유연성을 둘 수 있고 프록시, 게이트웨이같은 네트워크 기반의 중간 매체를 사용할 수 있게 함.
가장 중요한 항목 두가지로 요약하자면
1. URI는 정보의 자원을 표현해야 함
2. 자원에 대한 행위는 HTTP 메소드로 표현한다
REST의 6가지 규칙을 잘 지켜서 설계된 API를 RESTful API라고 함
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로 성능이 중요하다면 꼭 RESTful하게 구현할 필요는 없다.
✔️ 장점 : HTTP를 사용하기 때문에 HTTP의 특성을 그대로 반영하고 별도의 인프라 구축이 필요없다.
✔️ 단점 : 명확한 표준이 존재하지 않고, RESTful을 완전히 만족하는 API를 만들기는 매우 까다롭다는 점, 멱등성을 보장하기 힘들어서 REST API가 분산환경에 적합하지 않다는 점
출처 : https://meetup.toast.com/posts/92
https://github.com/ksundong/backend-interview-question
https://jy-tblog.tistory.com/24