REST API란?
-
REST(Representational State Transfer)는 HTTP 프로토콜을 기반으로 클라이언트가 서버의 리소스(HTML, CSS, 이미지, 폰트 등)에 접근하는 방식을 규정한 소프트웨어 아키텍처
-
REST의 원칙을 지킨 서비스 디자인을 RESTful하다고 표현하며 REST를 기반으로 서비스 API를 구현한 것을 REST API라고 한다.
-
RESTful하지 않은 API? (여러 가지 有)
- 모든 요청을 POST 방식으로만 요청하는 경우 : 리소스가 동일한 경우 메서드로 구분하게 되는데 삭제 요청에
POST메서드를 사용하는 방식은 RESTful하지 않다.
- 모든 요청을 POST 방식으로만 요청하는 경우 : 리소스가 동일한 경우 메서드로 구분하게 되는데 삭제 요청에
-
소프트웨어 아키텍처란?
- 소프트웨어 아키텍처(software architecture)란 소프트웨어의 구성요소 간 관계를 표현하고 소프트웨어 설계와 업그레이드를 통제하는 지침과 원칙
- 시스템 최적화를 위해 시스템의 구성과 동작 원리 등을 설계하는 일종의 설계도
-
HTTP란?
- HTTP(HyperText Transfer Protocol)는 일종의 프로토콜(통신 규약)이다. 컴퓨터나 원거리 통신 장비에서 메세지를 주고받는 양식과 규칙 체계를 의미한다.
- HTTP는 client와 server 간 이루어지는 request/response 프로토콜로 클라이언트가 HTTP 요청 메세지를 통해 HTML이나 어떠한 리소스를 요청하면 서버는 HTTP 응답 메세지를 통해 클라이언트에게 해당 리소스를 전송한다.
-
API란?
- API(Application Programming Interface)란 클라이언트가 리소스를 요청할 수 있도록 서버 측에서 제공하는 인터페이스를 의미한다.
- 일종의 창구처럼 특정 리소스의 검색 방법이나 출처에 대한 지식 없이도 API가 정의한 방식대로 리소스를 받을 수 있다.
REST API를 사용하고 있지만 RESTful하게 사용하는 개발자는 많지 않다
REST API가 필요한 이유
- 다양한 클라이언트의 등장 : 과거와 달리 여러 웹 브라우저(Edge, Chrome, Opera, Firefox), iOS, Android 애플리케이션 등 다양한 플랫폼(클라이언트)과의 통신에 대응할 수 있어야 한다.
- 애플리케이션 분리 및 통합 : 점차 애플리케이션의 규모가 커짐에 따라 애플리케이션을 모듈 or 기능 별로 분리 및 통합하는 것이 중요 이슈로 떠오르고 있다.
→ 서버가 각 클라이언트 종류 별로 통신 방식에 대응하지 않아도 된다. HTTP 통신을 기반으로 한 REST API를 사용하면 다른 모듈이나 애플리케이션이라 해도 상호 간 통신이 가능하기 때문이다.
→ 과거에는 서버로부터 데이터를 전달 받는 클라이언트가 PC 브라우저로 명확했지만 현재 다양한 클라이언트가 등장하며 일일이 대응하는 server를 만드는 것은 비효율적이다.
REST API의 장점 (REST API를 사용하는 이유)
- HTTP 표준 프로토콜을 사용하는 모든 플랫폼에서 사용할 수 있다.
- 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
- REST API는 직관적이다. REST API 메세지는 url과 method만으로 요청의 내용을 알 수 있어 의도를 쉽게 파악할 수 있다. (개발자 간 원활한 소통 기여)
- 서버와 클라이언트 간의 역할을 명확하게 분리한다.
app.js
const handleReadTodo = (isMain) => {
$.ajax({
type: 'GET',
url: '/todolist',
data: {},
success: (res) => {
// ...
});
};
const handleAddTodo = () => {
// ...
$.ajax({
type: 'POST',
url: '/todolist',
data: {
todo_give: todoItem,
isDone: false,
timestamp: timestamp,
},
success: (res) => {
alert(res['message']);
// ...
},
});
};app.py
@app.route('/todolist', methods=['GET'])
def read_todo():
todo_list = list(db.todolist.find({}, {'_id': False}))
return jsonify({'todolist': todo_list})
@app.route('/todolist', methods=['POST'])
def add_todo():
todo_receive = request.form['todo_give']
todo_isDone = request.form['isDone']
todo_timestamp = request.form['timestamp']
doc = {
'todo': todo_receive,
'isDone': todo_isDone,
'timestamp': todo_timestamp,
}
db.todolist.insert_one(doc)
return jsonify({'message': 'SUCCESS: UPDATE TODO'})REST API의 단점
- 표준이 존재하지 않는다. 어떤 메서드와 어떤 url을 써야 하는지 정해져 있지 않다. 개발자가 하기 나름
- HTTP Method의 형태가 제한적이다. REST API 기능 확장하려면 제한적인가??
- 구형 브라우저에서 지원하지 못하는 부분이 존재한다. (크롬 기준 10.3 이전 / 현재 크롬 버전 103.0.5060.114)
REST API의 특징
- Client-Server Architecture
- 클라이언트와 서버는 서로 독립적이어야 하며, 클라이언트는 URI 리소스만 알아야 한다.
- 클라이언트와 서버의 인터페이스가 변경되지 않는 한, 이들은 독립적으로 개발되거나 대체될 수 있어야 한다.
- Uniform Interface
- 일관된 인터페이스를 통해 단순화, 인터페이스 가시성 확보
- Stateless
- 서버가 클라이언트의 상태를 보존하지 않는다. 클라이언트 요청에 서버가 응답하고 나면 클라이언트와 서버 간의 연결은 끊긴다.
- 클라이언트는 서버가 요청을 이해하고 응답하는데 필요한 모든 정보를 제공해야 한다. (한번 통신하고 나면 연락이 끊기니까)
- HTTP 환경에서 클라이언트 상태 정보를 기억하기 위해 사용하는 것이 cookie / session
- 왜 stateless일까?
요청 안에 상태가 모두 들어가기 때문에 클라이언트는 서버가 무엇이든 동일한 방식으로 요청을 보낼 수 있다.
stateful ⇒ 서버는 클라이언트의 통신 상태를 저장한다. 따라서 클라이언트 상태는 서버에 종속적이다.
stateless ⇒ 서버 확장에 유리하다.
- Cacheable
- 서버는 Response cache-control 헤더에 해당 요청이 캐싱 가능한지 여부를 제공해야 한다. 이를 통해 응답 데이터의 재사용 가능 여부를 확인할 수 있다.
- Self-descriptiveness | 자체 표현 구조
- REST는 자체 표현 구조로 구성되어 REST API만으로 HTTP 요청을 이해할 수 있다.
- Layered System | 계층 구조
- client는 REST API server만 호출한다.
- REST server는 다중 계층으로 구성될 수 있다.
- API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조적으로 유연성을 줄 수 있다.
REST API의 설계 원칙
RESTful API를 설계하는 중심 규칙
- URI는 리소스를 표현해야 한다.
-
리소스를 식별할 수 있는 이름은 동사보다 명사 사용 권장 (행위에 대한 표현 지양)
// BAD GET /getTodos/1 GET /todos/read/1 // GOOD GET /todos/1
-
- 리소스에 대한 행위는 HTTP 요청 메서드로 표현한다.
- HTTP 요청 메서드는 클라이언트가 서버에게 요청의 종류와 목적(리소스에 대한 행위)을 알리는 방법으로 이를 이용하여 CRUD를 구현한다.
REST API의 구성 요소
- Resource (자원) : 자원 | URI
- Verb (행위) : 자원에 대한 행위 | HTTP 요청 메서드
- Representations (표현) : 자원에 대한 행위의 구체적 내용(request body에 담기는 데이터) | payload
HTTP 요청 메서드
GET/DELETE는 파라미터를 통해 요청을 보낸다.
GET vs. POST
-
GET
- 데이터 조회 목적으로 사용하는 방법
- URL에 데이터가 그대로 노출되기 때문에 보안 상 중요한 데이터를 포함하면 안 된다. -
POST
- 데이터 추가, 수정 목적으로 사용하는 방식 (GET보다 상대적으로 안전함) -
HTTP 요청/응답 메세지엔 HTTP Header와 HTTP Body로 구성되어 있다.
-
Header : 요청한 URL, methods, 요청 관련 기타 정보
-
Body : resource(실제 데이터 본문)
질문
- POST와 DELETE의 차이?
- 웹 개발 플러스 강의와 프로젝트 진행할 때에도 데이터 삭제 요청을 보낼 때
POST요청을 사용한 이유는? - 삭제할 때
POST요청을 사용해야 하는 이유가 있는 것인지, 아니면 강의 진행 편의 상POST요청으로 진행한 것인지?
- 웹 개발 플러스 강의와 프로젝트 진행할 때에도 데이터 삭제 요청을 보낼 때
POST vs. PUT
PUT vs. PATCH
- PUT은 리소스의 모든 속성을 수정할 때 사용한다.
- PATCH는 리소스의 일부분을 수정할 때 사용한다.
⇒ 데이터의 일부를 수정하는 경우 PUT 요청은 바뀌지 않는 속성도 모두 보내야 한다. (전달된 데이터 이외의 필드는 모두 null or default값으로 처리된다.)
⇒ 데이터의 일부를 수정하는 경우 PATCH 요청은 바뀌는 속성만 보내면 해당 부분만 수정된다.
PATCH /users/1
{
'age': 20
}
HTTP/1.1 200 OK
{
'name': 'John',
'age': 15
}PUT /users/1
{
'age': 20
}
HTTP/1.1 200 OK
{
'name': null,
'age': 20
}POST vs. DELETE
멱등성(idempotence)이란?
멱등성 : 여러 번 수행해도 결과가 같음
- POST는 매 호출마다 새로운 데이터 추가
- GET, PUT, DELETE는 같은 경로로 여러 번 호출해도 결과가 같다.
참조
https://ko.wikipedia.org/wiki/소프트웨어_구조
https://ko.wikipedia.org/wiki/REST
https://wnsgml972.github.io/platform/2021/03/06/importance-software-architecture/
https://ko.wikipedia.org/wiki/HTTP
https://code-lab1.tistory.com/194
https://www.redhat.com/ko/topics/api/what-is-a-rest-api
https://velog.io/@kjh03160/그런-REST-API로-괜찮은가
https://seunghyun90.tistory.com/42
https://appmaster.io/ko/blog/rest-apiran-mueosimyeo-dareun-yuhyeonggwa-eoddeohge-dareungayo
https://velog.io/@somday/RESTful-API-이란
https://velog.io/@modsiw/REST와-REST-API란
https://khj93.tistory.com/entry/네트워크-REST-API란-REST-RESTful이란
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
