면접을 보러가서 늘 공통적으로 물어보면서도 내가 너무 대략적으로 짚고 넘어간 부분이 REST 에 관한 부분이였다.
자원(resource)을 이름으로 구분지어서 주고 받고, HTTP 프로토콜을 이용한다. 정도로만 알고있고 디테일한 부분을 몰랐는데 막상 질문들어오니 막혔던..
REST 아키텍쳐 스타일을 따르는 API를 REST API라고 하며
균일한 인터페이스, 확장성, 무상태, 캐시가능성, 온디맨드 코드 의 특징을 가지고있다.
일단 무상태와 캐시가능성은 기존 HTTP 프로토콜의 요청이 캐시되고 연결과 상태를 유지하지않는(stateless) 특성이다.
균일한 인터페이스
클라이언트에게 제공될 API자원에 대한 균일한 인터페이스를 정해야 하는데 이때 4가지 제약이 따른다.
리소스가 URI로 식별되면 된다.
REST API를 빌드하면 URL을 통해 API에서 엑세스하는 리소스를 식별할 수 있다.
특정 리소스는 하나의 URL만 가져야한다.
이부분은 지금까지 프로젝트 하면서 알고있던 내용이였는데 개념으로 접하니까 처음에 ?? 싶었다.
예를 들어 URL을 통해 /userinfo/1 라고 가정했을때 1번 유저의 정보를 가져오는 API다 라고 식별할 수 있고
뒤의 유동적인 값에따라 각각 다른 요청이 발생한다 라고 알 수 있다.
기존에 사용만 하고 명확하게 정리되지 않았던 부분이였다.
표현을 통한 자원 조작
URL이 동일 하더라도 GET POST PUT DELETE 의 표현을 달리 하거나 미디어타입을 달리함으로서 리소스를 분리할 수 있다.
메소드를 분리하거나 요청헤더의 application/json 등의 미디어타입을 다르게 하는것으로 자원을 조작할 수 있다.
이부분도 예시를 들으니 이해가 되었다. 같은 API라도 POST냐 DELETE냐에 따라 달라지고 요청하는 타입도 json 밖에 써본적이 없지만 (axios) 변경을 통해서 다른 자원을 받을 수 있다는 얘기다.
자체 표현 구조
API 메세지만 보고도 무슨 요청인지 이해할 수 있는 구조로 되어있다.
이부분은 앞에 리소스 식별과 거의 비슷한 맥락인것 같다 .
GET /userinfo/1
만 보고도 경우에 1번유저의 정보를 조회한다. 라는 행위를 알 수 있는,
계층화 시스템
클라이언트에서는 REST API만 호출하지만 서버에서는 계층을 둘 수 있다.
순수 비즈니스 로직을 수행하는 API 서버와 사용자인증, 암호화 하는 서버에 계층을 두는 등 구조상 유연성을 둘 수 있다.
온디맨드 코드
서버에서 보낸 코드를 클라이언트에서 실행할 수 있는 특성이다.
HTML 파일과 JS파일을 받아와서 JS 파일을 실행시켜서 렌더링 하는것이 온디맨드 코드라고 볼 수 있다.
