API (Application Programming Interface)
클라이언트가 원하는 응답을 얻기위해 서버에 요청하는 방법
& 요청했을 때 받을 수 있는 응답 형식
서버에서 제시해준다
HTTP의 장점을 최대한 활용할 수 있는 구조
로이 필딩 - Wiki_en
API 요청과 응답을 제대로 보내고 받게 하는 형식
오고 가는 데이터를 제대로 표현(Representational) 하고
제대로 표현된 데이터의 상태를 전송(전달) (State Transfer) 한다
[데이터 = 자원(Resourses)]
CRUD
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
REST API = REST한 (RESTful) API
= API의 형식이 RESTful하다 = REST 기반으로 API가 구현되었다
REST API를 잘 적용하기 위한 4단계 모델
리차드슨 성숙도 모델 - Wike_en
REST API라고 하진 않는다
요청 - 데이터를 제대로 된 URI로 표현
= 원하는 데이터에 맞는 엔드포인트(Endpoint)를 사용
= 확인요청: /doctors/허준
이라는 데이터를 명시함
= 예약요청: /slots/123
이라는 데이터를 명시함
좋은 엔드포인트?
데이터를 확실히 표현하는 명사 형태의 단어
동사, HTTP 메소드, 혹은 어떤 행위에 대한 단어는 쓰지 말자
응답 - 데이터 활용이 어떻게 되었는지 상황을 전달
= 예약 성공/실패 여부 반환
요청 - 상황에 따라 적절한 HTTP 메소드를 사용
CRUD
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
= 예약 가능한 시간 확인 : READ → GET
= 특정 시간에 예약 : CREATE → POST
GET
은 body
없이 query를 이용
응답 - 상황에 맞는 HTTP 상태 코드 작성
- 1xx (정보): 요청을 받았으며 프로세스를 계속한다
- 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
- 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
- 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
- 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다
= 특정 시간에 예약하는 POST
요청은 새롭게 예약이 생성되는 경우
→ 응답이 어떻게 반환되는지도 중요
→ 성공했다면 201 Created
, 실패했다면 409 Conflict
등
HTTP 메소드 사용규칙
GET
- 서버의 데이터를 변화시키지 않는 요청에 사용POST
- 요청마다 새로운 리소스를 생성PUT
- 요청마다 같은 리소스를 반환 [멱등(idempotent)하다]
=POST
와PUT
은 잘 구분해서 사용해야한다PATCH
- 요청마다 다른 리소스를 반환 [멱등(idempotent)하지 않다]
=PUT
과PATCH
도 잘 구분해서 사용해야한다
=PUT
: 교체,PATCH
: 수정
여기까지 잘 지켰다면 대체로 잘 작성된 API
요청은 2단계와 동일
응답 - HATEOAS 원칙을 지킴
HATEOAS (Hypermedia As The Engine Of Application State)
RESTful API를 사용하는 클라이언트가 서버와 동적인 상호작용이 가능하도록 하는 것
요청을 한 데이터에 맞는 추가 요청을 할 수 있는 URI를 응답에 더해서 보내준다
= 예약 시간을 확인 → 그 시간에 예약을 할 수 있게 하는 링크
= 특정 시간에 예약 → 내 예약 확인 or 예약 취소 링크
Reference
codestates
REST란? REST API란? RESTful이란?