프론트엔드 개발자 채용공고에 항상 있는
REST API에 대한 이해가 훌륭하고 이를 활용할 줄 아시는 분
오늘 그 REST API에 대해 알아보자.
이미지 출처 : https://mannhowie.com/rest-api
REpresentational State Transfer의 약자이다.
1) Uniform Interface : URI로 지정된 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
2) Stateless : 작업을 위한 별도 상태정보가 없다. 즉 저장할 상태 데이터, 세션, 쿠키 등이 없기 때문에 서버의 단순한 구현이 가능하다. 들어오는 요청만 잘 처리하면 된다.
3) Cacheable : HTTP의 웹 표준을 사용하기 때문에, HTTP가 캐싱기능을 활용할 수 있다. (Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다고한다…)
4) Code on Demand(optional) :서버가 클라이언트에게 기능을 확장하면서 실행가능한 코드를 보낼 수 있다. CoD의 특징은 클라이언트 케파를 향상 시키기 위해 웹브라우저가 실행가능한 코드를 보낼 수 있도록한 의도이다. 서버는 동적으로 클라이언트에게 부가적인 행동을 제공할 수 있는데, 이를테면 서버는 클라이언트가 특정 동작을 수행하거나 API로부터 받은 데이터를 조작하도록 script를 함께 보낼 수 있다.
5) Client-Server structure : 서버는 REST API 제공, 클라이언트는 클라이언트단의 정보만을 직접 관리하면서 서로간의 의존성을 줄인다. (Decouple server with client)
6) Layered system : REST 서버는 다중 계층으로 이뤄져있어, 중간에 여러 구조층(보안, 암호화 계층 등)을 추가할 수 있고 미들웨어 사용도 가능하다.
Resource
, verb
, presentations
3가지 요소로 구성되어있다.
resource는 자원, verb는 자원에 대한 행위, presentation은 자원에 대한 행위의 구체적인 내용을 담는다.
resource는 URI를 통해 표현하고, verb는 http 요청메서드, presentations는 payload를 통해 표현한다.
URI는 리소스를 표현한다.
# bad
GET /todos/getToDos/1
GET /todos/show/1
# good
GET todos/1
리소스에 대한 행위는 HTTP 요청 메서드로 표현한다.
이러한 REST의 원칙을 잘 준수하여 만들어진 API를 ‘RESTful’하다고 하여, RESTful API라고 일컫는다.
REST를 사용했다고 해서 모두가 RESTful한 것은 아니며 REST API의 설계규칙을 올바르게 지킨 시스템만이 RESTful 하다고 말할 수 있다.
HTTP 통신을 할 때 쓰이는 메서드를 REST API에서도 활용한다. get과 delete 통신을 할 때는 payload가 필수가 아닌 점과 patch와 put 통신의 차이도 알아두면 좋다.
Method | 목적 | Payload |
---|---|---|
GET | 조회 | x |
POST | 생성 | O |
PUT | 리소스 전체 교체 | O |
PATCH | 리소스 일부 수정 | O |
DELETE | 삭제 | x |
대표적인 응답 상태코드이다. 모든 상태 코드들을 외울 필요는 없지만 대표적인 코드들은 기억해두면 편리하다.
상태코드 | 설명 | |
---|---|---|
200 | 일반 성공 응답 | 성공 |
201 | POST 메서드 성공 응답 | 성공 |
301 | Permanently Moved, 영구적으로 URL이 이동되어 새로운 URL로 리다이렉션 시킴 | 리다이렉션 |
400 | 서버가 처리할 수 없는 잘못된 요청 | 클라이언트 요청에러 |
401 | Unauthorized (권한없음) | 클라이언트 요청에러 |
403 | 접근금지 | 클라이언트 요청에러 |
404 | 리소스를 찾을 수 없음(Not found) | 클라이언트 요청에러 |
405 | 허용되지 않는 http method 사용 | 클라이언트 요청에러 |
500 | 내부 서버 오류 | 서버에러 |