REST 는 자원을 이름으로 구분하여 해당 자원의 상태를 주고, 받는 모든 것이다.
구성요소
REST의 핵심 3가지 요소는 아래와 같다.
1. 자원
2. 조작
3. 표현
자원
- 서버에 있는 것 == DB 안에 들어가 있는 데이터를 의미한다.
- URI를 통해 자원을 명시하고, 구분할 수 있다.
조작
- Client는 HTTP Method (post,get...) 를 이용하여 지정한 자원에 대한 조작을 요청한다.
표현
- Client가 Sever에 자원에 대한 요청을 하면, Server에서 응답을 보낸다.
클라이언트와 서버 사이에서, HTTP URL을 통해 자원을 명시하고, Method를 통해 조작을 요청하고, 이에 대한 응답을 받는 것
RestFul
Rest 기본 원칙 6가지를 지키는 것을 Restful 하다고 표현한다.
1. 클라이언트 - 서버 모델
- 서버와 클라이언트의 역할이 분리되어 독립적으로 교체 및 개발이 가능하다.
- UI와 데이터 처리 영역이 분리될 수 있어 유지 보수가 간단하다.
2. stateless (무상태)
반대말로는 stateful(상태유지) 이다. 이 내용 먼저 확인해보자
stateful
- TCP 방식
- 서버가 클라이언트의 상태를 보존하는 것이다.
- 서버에서 클라이언트의 상태 정보를 저장하고 있는 것
- stateful 문제점 :
해당 서버가 멈추거나 다른 서버를 이용해야 할 때 상태값을 갖고 있지 못해 문제가 생길 수 있다.
서버가 처리할 수 있는 클라이언트 수를 초과할 때, 용량의 한계 때문에 그 다음 클라이언트는 기존의 클라이언트가 빠져야 처리 가능하다. => 현업에서는 상태 데이터를 캐시서버(Redis)에 저장하여 사용한다.
stateless
- HTTP, UDP (데이터를 전송할 때마다 연결하고 끊어버린다.)
- 세션 상태가 서버에 저장되어 있지 않은 상태,
- 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할 때 데이터를 실어 보내는 형식
- 상태관리는 전적으로 클라이언트에게 책임이 있다.
- server는 단순히 요청이 오면 응답만 하기 때문에 상태 유지에 대한 부하가 줄어든다.
- JWT 토큰 이 stateless 특징을 유지하면서도 로그인 상태 유지를 가능하게 하는 기술이다.
- 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할 때 넘겨줌으로써 내가 로그인 됐음을 인증하는 방식- stateless 문제점 :
매번 요청때마다 자신의 부가 정보를 줘야해서 더 많은 데이터를 소모한다.
3. 캐시 가능
- REST 는 웹 표준인 HTTP를 그대로 사용하기 때문에, HTTP가 가진 캐싱 기능을 적용할 수 있다.
4. 자체 표현 구조
- REST API 만 보고도 쉽게 이해할 수 있다.
- GET, POST, PUT, DELETE
5. 계층화 (Layerd System)
- 클라이언트 입장에서는 REST API 서버만 호출한다.
- 하지만, REST 서버는 다중 계층으로 구성될 수 있다.
- 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 도 있고,
- Proxy,게이트웨이 같이 네트워크 기반의 중간매체를 사용할 수도 있다.
6. Uniform Interface
- HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 사용이 가능한 인터페이스 스타일이다.
- 특정 플랫폼에 종속되지 않고 어디서나 사용가능하다. (IOS,Android)
REST API Design 가이드
1. URI 의 리소스 명은 소문자를 사용하고, 동사보다 명사를 사용하자.
GET /member/delete/1
=> 단수명사 보다는 복수명사를 사용하자.
=> 행위를 나타내는 표현이 들어가는 것을 지양하자.
2. 자원에 대한 행위는 HTTP 메서드를 사용하자.
DELETE /members/1
3. 하이픈( - ) ok but 밑줄( _ ) X
4. 파일의 확장자는 URI에 포함하지 않는다. 타입은 헤더에 컨텐츠 타입으로 알려주자
5. 관계표현
GET /users/{userId}/devices 유저가 갖고 있는 목록
GET /users/{userId}/likes/devices 유저가 좋아하는 디바이스 목록
response status
200번
- 200 : 클라이언트의 요청을 정상적으로 수행
- 201 : 생성 작업이 성공됨을 알려줌
300번
- 301 : 요청한 리소스에 대한 URI가 변경되었을 때 사용
400번
- 400 : 클라이언트의 요청이 부적절한 경우
- 401 : 인증되지 않은 클라이언트의 요청에 대한 응답
- 403 : 인가되지 않은, 응답하고 싶지 않은 리소스에 접근하려고 하는 응답
- 404 : 요청한 응답을 찾을 수 없을 경우의 응답
- 405 : 요청 리소스에 대해 사용 불가능한 method를 이용했을 때의 응답
500번
- 500 : 서버에 문제가 있을 경우 사용하는 응답 코드
Reference
주경야독