왜 알아야 할까?
- 프론트엔드와 백엔드가 소통하는 엔드포인트에 관한 개념
- 서로 더 원활한 의사소통을 위해 알아둬야함 (엔드포인트 회의갔는데..RESTful 개념을 모른다..? 안돼 😱)
- REST스럽지가 않은걸..? REST스럽지 않아서 엔드포인트 수정합니다.
개념
RESTful API
: REST 아키텍쳐 스타일에 부합하는 api
REST
REpresentational State Transfer
: 표현된 상태 전송
표현된 상태 ? 클라이언트, 서버에서 데이터 원본을 주고받는 게 아니라 현재 시점에서 DB의 상태를 주고받는 것이다
// request -> 2번 유저정보를 줘! json 형태로(Accept) GET https://iamserver.com/api/users/2 Host: iamserver.com Accept: application/json // response -> 너가 말한 요청 이해했고(200), 응답보낸다~ Content-Type은 json이야! HTTP/1.1 200 OK Content-Length: 45 Content-Type: application/json { id: 2, name: 'Suhwa', nickName: 'Pur', }
- Response로 온 값이 DB데이터 그 자체가 아니라, 현재 시점에서 데이터의 상태를 주고받음
- 현재시점에선 이름이 Suhwa → 이름변경 CS → 이름변경 api로 변경됐다고 알려주지 않나요?
- 원본 데이터를 받아왔다면, 알려줄 필요가 없죠! 하지만 DB의 상태를 주고받기때문에 변경됐다고 api로 알려주는 거죠!
- 즉, 서버가 보내준 JSON은 데이터베이스에 저장되어있는 원본 데이터 리소스의 현재 상태를 표현한 것
위에 적힌 Accept, Content-Type 같은 부분은 “HTTP 완벽가이드”책 참고해서 학습해보는 거 추천
어떻게 엔드포인트를 정해야 서버/클라이언트가 소통하기 좋을까?
Roy Fielding 아저씨: hey, how about REST concept?
RESTful API
REST 아키텍쳐 스타일에 부합하는 api
- REST 아키텍쳐: Client-Server, Stateless, Cache, Uniform Interface, Layered System, Code-On-Demand 등
- 핵심 포인트는, 리소스를 주고받을 때 어떻게하면 더 명확하게 표현할 수 있을지
- 이해하기 쉬운 엔드포인트에 집중하는 아키텍쳐 스타일
100번째 사용자의 이메일을 수정해주세요
- 어떤 리소스? 100번째 사용자 이메일
- 어떤 행위? 수정
URI를 통해 어떤 리소스인지 표현
URI: Uniform Resource Identifiers
GET /users/2/profile-image
- 리소스 간의 계층구조를 / 를 사용해 표현함
- 뒤로 갈수록 하위계층구조
- 행위가 표현되면 안됨 → 행위는 HTTP 메서드가 담당
POST /users/2/delete // 생성인지? 삭제인지?
HTTP 메서드를 통해 어떤 행위인지 표현
- 대부분 CRUD에 기반한 아래 5가지 메서드를 많이 사용
GET | 리소스 조회 |
PUT | 리소스 전체 수정 |
DELETE | 리소스 삭제 |
POST | 리소스 생성 |
PATCH | 리소스 일부 수정 |
정리
- RESTful API는 엔드포인트의 가이드라인(엔드포인트 표준규칙)
- 엔드포인트에 필요한 리소스 / 행위를 각각 따로 담당
- 어떤 리소스인지? - URI
- 어떤 행위인지? - HTTP 메소드(get, post, put, delete…)
- RESTful API, 엔드포인트만 봐도 어떤 동작을 하는 API인지 이해할 수 있을 정도로 명확한 API
참고자료
추천자료
- RESTful 개념을 최초로 제안한 논문
- RESTful 영상자료 (47분)
