Search
🗃️

REST APIs

1. REST 아키텍쳐 스타일

가. REST API

1) 개념

•
정의: 'REST 아키텍쳐 스타일'을 따르는 API
•
REST 아키텍쳐: 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일
→ 아키텍쳐 스타일: 제약조건의 집합

나. REST 아키텍쳐 스타일

1) 잘 지키는 제약조건

HTTP만 따라도 optional을 제외한 네 가지 자동 만족
•
Client-Server
•
Stateless
•
cache
•
layered system
•
code-on-demand(optional)
→ 자바스크립트

2) 잘 안지키는 제약조건

•
Uniform Interface

2. Uniform Interface에 대하여

가. 잘 지키는 제약조건

1) Identification Of Resources

•
URI 사용에 따른 엔티티 식별

2) Manipulation of Resources through representations

•
POST, GET, PUT, DELET 사용에 따른 엔티티 조작

나. 잘 안지키는 제약조건

1) Self-Descriptive Messages

•
외부의 도움 없이 메시지만으로 충분히 해석가능한 상태

2) HATEOAS: Hypermedia as the engine of application state

•
링크를 통해 상태변경을 할 수 있는 상태

3. Self-Descriptive Message & HATEOAS

가. Self-Descriptive Message 만족

1) Custom media type

2) Profile link relation

나. HATEOAS 만족

1) HTTP 본문에 Link 추가

2) HTTP 헤더에 Link 추가

4. Params

가. Header Param

1) 목적

2) 사용법

나. Path Param

1) 목적

•
URI End Point의 일부로 사용되어, 엔티티 구분
•
자원의 구체적인 정의에 사용됨

2) 사용법

•
GET, service/todoservice/user/12322/todos/123
→ service/todoservice/user/{userId}/todos/{todoId}
→ user(id=12322)의 todo(id=123) 요청

다. Query String Param

1) 목적

•
데이터 필터링: 정렬 매개변수 전달
•
페이징: limit, offset 전달

2) 사용법

•
GET, service/todoservice/user/{12322}/todos?category={done}
→ service/todoservice/user/{userId}/todos?category={category}
→ user(id=12322)의 category가 done인 todos 조회

라. Requst Body Param

1) 목적

•
엔티티 생성, 수정에 따른 엔티티 정보를 URI로 노출 방지

2) 사용법

•
POST, PUT, PATCH 메소드와 사용
•
POST, service/todoservice/user/{12322}/todos
•
PUT, service/todoservice/user/{12322}/todos/{todoId}

Reference

•
이응준, naver d2, 그런 REST API로 괜찮은가, https://www.youtube.com/watch?v=RP_f5dMoHFc
•
REST API Params