1. REST API란?
1-1. REST (Representational State Transfer)
Representational: 표현적인
State: 상태
Transfer: 전송
- 네트워크 리소스를 정의하고 처리하는 방법을 설명하는 일련의 원칙을 기반으로 하는 소프트웨어 아키텍처 or 아키텍처 스타일
- REST의 목적은, 개발자들이 함께 개발하기 때문에 통용되는 방식을 만드는 것이다.
- RESTful하게 만든 API는 요청을 보내주는 주소만으로도 어떤걸 요청하는지 알 수 있다.
즉, 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준.
1-2. REST의 구성
-
자원(Resource) - URI
→ URI에는 리소스에 대한 부분만 나타내야한다.
-
행위(Verb) - HTTP 메소드
→ 행위에 대한 부분은 HTTP 메소드로 표현한다.
-
표현(Representations)
→ 클라이언트 응답에 대한 반응을 서버는 표현해야한다.
→ REST에서 주로 JSON이나 XML로 표현함.
1-3. REST의 특징
Uniform (균일한 인터페이스)
요청이 URI로 지정한 리소스에 대한 요청으로 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.
Stateless(무상태성)
-
API에 상태정보(세션 or 쿠키)를 따로 저장하고 관리 X
→ 즉, 각각 요청을 별개라고 생각하고 처리
→ 이전의 요청들과 현재의 요청이 연관되면 안됨.
→ API 서버는 들어오는 요청만을 단순히 처리
→ 서비스의 자유도 향상, 구현 단순.
Cacheable (캐시 가능)
-
HTTP 기존 웹표준을 그대로 사용 → HTTP에서 제공하는 캐시 기능을 그대로 이용하여 캐시를 구현 할 수 있음.
-
Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있어서 대량 요청에 효율적
Self-descriptiveness (자체 표현 구조) → 현재는 제외됨.
- API 메세지만 보고도 어떤 의도인지 파악가능.
Client-Server 구조
- 관심사 분리를 위해 클라이언트-서버 구조로 구성.
- 클라이언트는 서버에 리소스를 요청하고, 서버는 클라이언트의 요청을 처리하고 응답함.
계층형 구조
- 서버는 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 함.
주문형 코드 (옵션)
- 대부부분 XML or JSON으로 정적 표현을 보내지만 필요한 경우 실행가능한 코드를 요청할 수 있다.
ex) 클라이언트가 API를 호출하여 UI 위젯 렌더링 코드를 받을 수 있다.
2. 난 잘 모르겠고 어떻게 하면 RESTful한건데?
행위와 자원을 철저하게 나누어야한다
2-1. 흔히 실수하는 예시
2-2. 🔥가장 중요 포인트🔥
- URI는 리소스만 담겨야함.
ex) 미네랄을 캐라 → 미네랄이 리소스.
- 이렇게 URI에는 리소스만 담겨야한다.
하지만
- 리소스만 담기면 행위가 모호해지고 중복이 생김
이러한 중복을 구분해주는 것이 HTTP 메소드
- 행위(캐라) 를 HTTP 메소드가 해줌!
3. HTTP 메소드의 종류
GET → 리소스 조회
GET /members
- GET은 메세지 바디를 사용하지 않는다.
- 원래 메세지 바디 지원 X → 현재는 지원되지만 지원되지 않는 곳이 많아서 권장 X
- 멱등성 O
- 캐시가능 O
POST → 요청 데이터 처리, 등록
POST /members
- 메세지 바디를 통해 서버로 요청 데이터를 전달.
- 주로 신규 리소스를 등록 할 때 사용.
- 리소스를 변경할 때도 사용.
- 멱등성 X
- 프로세스를 처리해야 하는 경우에도 사용. ex) 배달 시작했다고 버튼 누를때
- 다른 메소드로 처리하기 애매한 경우 → post는 만능!
- 캐시가능 O BUT 바디 안에 데이터까지 캐시와 모두 맞춰야하기 때문에 실제로는 사용 X
PUT → 리소스를 대체, 해당 리소스가 없으면 생성
PUT /members/2
- 클라이언트가 리소스를 식별 할 수 있음 → 정확한 결로를 알고 있다는 것이 POST와의 차이점.
- 덮어쓰기이기 때문에 기존 리소스를 통째로 바꿀때도 사용 → 때문에 사용할때 주의해야함.
PATCH → 리소스 부분 변경
PATCH /members/2
- 부분적으로 리소스의 내용을 바꿀 수 있음.
- PATHCH가 지원이 안되는 곳도 있음 → POST로 부분 변경해야함.
DELETE → 리소스 삭제
DELETE /member/2
- 리소스를 삭제한다.
4. 메소드 비교
4-1. GET vs POST
GET
- 정보를 요청
- 안전 O → 기존의 리소스가 바뀔 일이 없음
- 멱등 O → 같은 호출이던 한번던 100번이던 최종 결과물이 같음.
POST
- 정보를 등록
- 안전 X → 리소스가 바뀜
- 멱등 X → 두번 결재 → 중복결재로 처리되기 때문
++PUT은 → 멱등 O → 몇번을 결재해도 앞에 결재가 사라지고 새로운 결재로 덮어버리기 때문
4-2. POST vs PUT
PUT도 해당 리소스가 없으면 등록하는건 같은데 차이가 무엇인가?
- 가장 명확한 차이는 클라이언트의 리소스 식별 유무이다.
- POST는 클라이언트가 리소스를 식별X → 서버가 리소스의 위치를 결정한다.
POST /members
- PUT은 클라이언트가 리소스를 식별O → 클라이언트가 리소스의 위치를 결정한다.
PUT /members/2
4-3. PUT vs PATCH
PUT도 기존 리소스 변경이고 PATCH도 기존 리소스 변경인데 차이가 무엇인가?
- PUT
- 기존에 있던 리소스를 덮어버림.
- 기존 리소스가
name="a", age="20"에서 나이만 21로 변경하고 싶다면name="a", age="21"로 모든 리소스를 요청해야함. age="20"이렇게 이름을 제외하고 보내면 리소스에name은 사라지고age만 남게됨.
- PATCH
- 기존에 있던 리소스 중 원하는 부분만 수정.
- 기존 리소스가
name="a", age="20"에서 나이만 21로 변경하고 싶다면age="21"로 나이만 보내도 무관함. - 단, 너무 오래된 곳에서는 PATCH를 지원안할 수도 있음 → 이 경우엔 POST로 변경해야함.
restfulapi.net의 한마디
ㅋ0ㅋ
All the above constraints help you build a truly RESTful API, and you should follow them. Still, at times, you may find yourself violating one or two constraints. Do not worry; you are still making a RESTful API – but not “truly RESTful.”
