goal
- REST API 와 Routing 이해하기
REST API & Routing
- 서버에 요청을 보낼 때, "주소"를 통해서, 요청의 내용을 표현한다.
(ex. 주소가/index.html이면, 서버의 index.html을 보내달라는 의미) - 이처럼, 주소를 통해 요청이 들어오므로, 서버가 이해하기 쉬운 주소를 사용하는 것이 좋다. (리소스마다 서로 API 규칙이 다르기 때문에)
- 이때 등장하는 개념이 REST API이다.
- 웹 서비스를 만드는데 사용되는 제약(constraint)들의 모음이라고 할 수 있다.
REST API (REpresentational State Transfer)
- REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스
- 네트워크 구조의 한 형식
-> REST is a set of architectural constraints, not a protocol or a standard. - 서버의 자원을 정의하고, 자원에 대한 주소를 지정하는 방법을 가리킨다.
- 여기서 주소는 "명사"를 사용한다. (ex.
/user)
- 여기서 주소는 "명사"를 사용한다. (ex.
- REST API는 주소말고도, http 요청 메서드도 사용한다.
- http 요청 메서드는 : GET, POST, PUT, PATCH, DELETE 등
- 주소 하나가 여러개의 http 요청메서드를 가질 수도 있다.
| client 모바일 앱 웹 브라우저 다른 서버 | <---- http 통신 ----> | Node.js 서버 GET POST PUT PATCH DELETE |
|---|
6가지 제약 (Constraint)
Client-Server - http
Stateless - http
Cacheable - http
Uniform interface - http
Layered system - http
Code on demand - js
REST API를 따르는 서버를 Restful API라고 표현한다.
-
Restful API를 만들때는, 주소구조부터 정의하는 것이 좋다.
-
서버 주소 구조 ex)
http 메소드 주소 역할 GET / index.js 파일 제공 GET /user 사용자 목록 제공 POST /user 사용자 등록 PUT /user/id 특정 id의 사용자 수정
API가 RESTful로 간주되려면 다음 기준을 따라야 한다.
- 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
- 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
- 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
- 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스. 여기에 필요한 것은 다음과 같습니다.
- 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.
- 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).
- 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
- 하이퍼미디어: 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
- 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
- 코드 온디맨드(선택 사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능.
출처 : https://www.redhat.com/ko/topics/api/what-is-a-rest-api
delilah's journey