최근 예전에 했던 내용을 기억해야 할 일이 생겼는데 너무 까마득해서 정리해본 글
REST
: Representational State Transfer
"하나의 URI는 하나의 고유 resource를 대표하도록 설계된다."
왜 RESTful하게 설계할까?
최근 디바이스가 다양해짐에 따라 디바이스 종류에 상관없이 공통으로 데이터를 처리할 수 있도록 하기 위함.
REST API
사용자가 어떤 요청을 하든 HTML을 리턴하지 않고 사용자가 필요로 하는 데이터만을 반환해주는 방식
REST 구성
- Resource 자원: URI
- Verb 행위: HTTP method
- Representations 표현
REST 특징
-
Uniform 유니폼 인터페이스
: URI로 지정한 리소스에 대한 조작을 통일되고 한정된 인터페이스로 수행하는 아키텍처 스타일 -
Stateless 무상태성
: 상태 정보를 따로 저장, 관리하지 않음.
세션 정보, 쿠키 정보를 별도로 저장/관리하지 않기 때문에 API는 단순히 들어오는 요청만을 처리함.
→ 구현이 단순해짐 -
Cacheable 캐시 가능
: REST의 가장 큰 특징 중 하나는 HTTP 기존 웹 표준을 그대로 사용해 기존 인프라를 그대로 활용 가능함.
그래서 캐싱 기능 사용이 가능해짐. -
Self-descriptiveness 자체 표현 구조
: REST의 또 다른 가장 큰 특징 중 하나로 REST API 메시지만 보고 쉽게 이해할 수 있는 자체 표현 구조로 되어있음. -
Client-Server 구조
: 클라이언트와 서버의 역할이 명확히 구분되어 서로 간 의존성이 줄어들음. -
계층형 구조
: 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상 유연성을 두며, PROXY, gateway 같은 네트워크 기반 중간 매체를 사용할 수 있도록 함.
REST API 디자인 가이드
1. URI는 정보의 자원을 표현
: URI에 행위에 대한 표현이 들어가면 안됨.
2. 자원에 대한 행위는 HTTP method로 표현
: HTTP method - GET, POST, PUT, DELETE
(POST로 거의 모든 행위가 가능함)
URI는 자원을 표현하는 것에 집중하고 행위에 대한 정의는 HTTP method를 통해 설계한다.
주의사항
/는 계층 관계를 나타냄- URI 마지막 문자로
/포함 금지 -는 URI 가독성을 높이는데 사용_는 URI에 사용 금지- URI는 소문자로 구성
- 파일 확장자는 URI에 포함 금지
HTTP 상태 응답 코드
간략히 설명
2xx: 성공
4xx: "클라이언트가 잘못했어요."
5xx: "서버가 잘못했어요."
