2020. 10. 22. 20:23ㆍ풀스택을 향하여 - 백엔드/Node.js
REST API 란?
REST : Representational State Transfer
API : Application Programming Interface
REST API Routung
클라이언트와 서버는 어떻게 REST API를 이용해서 통신할까? 전통적인 방법으로는 링크 태그를 이용하거나, 폼 태그를 이용하였다. HTTP 메서드와 경로를 같이 보냈다. Ajax나 fetch API를 써서 비동기로 이러한 요청을 보냈다.
이를 API Endpoint라고 한다. API Endpoint란 Http 메서드(Post, Get…)와 상대경로의 조합을 말한다.
여기서 Http 메서드들 중 GET과 POST 만이 HTML 태그를 이용해서 사용할 수 있고, 나머지는 브라우저 상의 자바스크립트를 통해서만 사용될 수 있다.
GET : READ
POST : CREATE (No Overwrite)
PUT : UPDATE (Overwrite)
PATCH : UPDATE (No Overwrite)
DELETE : DELETE
OPTIONS : 브라우저를 통해 자동으로 보내짐
하지만 위의 메서드들 중 어떤 종류의 메서드를 이용하는 요청이 들어와도, 서버에서 어떤 일을 하게 만들지는 개발자의 마음이다. 하지만 일반적으로, 이 요청들에 맞는 작업을 해주는 것이 좋다. 메서드에 따라 그저 어떤 제한이 있다고 생각할 필요는 없다.
- 브라우저는 요청을 보내기 전에, 실제로 보낼 수 있는지를 체크하기 위해 OPTIONS 메서드로 서버에게 요청을 보내본다
REST API 의 원칙
1. Uniform Interface (일관적인 인터페이스)
: 명시적으로 응답과 데이터 구조를 알 수 있도록 알기 쉬운 Endpoint 를 만들어야 한다 - 결과를 예측할 수 있어야 한다. 또한 일관적인 Endpoint 스타일과 구조를 유지해야 하며 변경이 있어서는 안된다.
2. Stateless Interaction (상태 없는 인터페이스)
: 서버와 클라이언트 간의 연결 기록 혹은 연결을 통해 남겨진 데이터를 이용하는 로직이 있어서는 안된다. 둘은 완전하게 분리되어야 한다. 요청과 응답은 완전히 서로 분리되어서 관리되어야 한다. 세션을 저장한다던지, 그런 것은 지양해라
3.기타
: 캐시 원칙 : 서버는 클라이언트가 응답의 헤더를 저장하도록 설정할 수 있다.
: 클라이언트 - 서버 원칙 : 클라이언트가 서비스 이용에 있어서 어떤 데이터를 저장할 필요가 있어서는 안된다. 상태의 저장은 서버가 책임져야 한다.
: 계층화 시스템 원칙 : 서버는 요청을 받았다고 해서 그 서버에서만 요청을 처리할 필요는 없다. 다른 서버로 (다른 API 요청) 요청을 보내서 처리할 수도 있다.
: 어떤 엔드포인트에는 실행 가능한 코드를 클라이언트로 보내는 로직이 실행될 수 있다.
CORS
Cross-Origin-Resource-Sharing
클라이언트와 서버가 있을 때, 둘의 도메인이 같다면 둘 사이의 요청과 응답이 일어나도 문제는 일어나지 않는다. 하지만 만일 도메인(포트번호가 달라도!)이 서로 다르다면 CORS가 발생한다.
이 에러는 브라우저 내에 내장된 보안 시스템이 동작시키는 것으로, 만일 클라이언트 사이드의 도메인과 요청을 보내는 서버사이드의 도메인이 다르다면 이렇게 생기는 연결을 위험한 것으로 보고 막아버리는 것이다.
이 CORS는 서버사이드에서 처리하는 것이 좋다.