REST (Representational State Transfer)
-Http를 이용한 서버를 구현할때 지켜야 하는 설계 원칙
-서버와 클라이언트 사이의 결합성(Coupling) 감소에 목표를 둠
-성능 향상
-확장성 확보
-사용 편의성 증대
사용자(클라이언트)는 데이터 표현의 상태(게시물 폼)를 전달을 하고
서버는 그 데이터 표현의 상태를 데이터 베이스라는곳에 저장한다.
1. 클라이언트 서버 Architecture
-클라이언트와 서버의 역할 분리
-서버는 데이터가 어떤 방식으로 표현되는지 몰라도 됨
-클라이언트도 데이터가 어떻게 저장되는지 몰라도 됨(댓글 쓸때 게시글 article_id(FK)를 고려하지 않는다.)
-양측의 독립적 발전을 추구
2. Stateless
-클라이언트가 보내는 개별적인 요청은 각각이 요청을 표현하기 충분(모든데이터를 포함) 하여야 한다
-즉 서버가 클라이언트가 몇번째 보낸 요청인지, 이전에 보낸 요청에 데이터가 어떤지 기억할 필요가 없어야 한다.
3. Cacheability
-서버에서 보내주는 응답은 캐시 가능성에 대해서 표현해 주어야 한다.(네이버 로고, 아이콘)
-Cache-Control Header
4. Layered System
-클라이언트가 서버에 요청이 도달하기까지의 과정을 알 필요 없고, 영향 받지도 않아야 한다.
(예시: Aws -> EC2 -> nginx -> Spring Boot)
-즉 클라이언트는 요청만 보내면 되지 과정은 몰라도 된다.
5. Code On Demand(Optional, 선택적)
-실행 가능한 코드를 전달함으로서 일시적으로 클라이언트의 기능을 확장
-JavaScript와 브라우저
6. Uniform Interface
-일관된 인터페이스를 가지고 있어야 한다.
-Rest에서 가장 근본적인 제약사항
-RESTful API가 가지는 인터페이스를 묘사한 제약사항
클라이언트가 서버에 요청하고 있는 자원이 요청자체로 식별이 되어야 한다
(즉, URL에 요구하는 자원이 무엇인지 명확히 표현)
예시: GET /students/{studentId}
자원에 대하여 조작을 할때, 그 자원의 상태나 표현으로 조작이 가능하여야 함
예시: 게시물 새로 쓰기(create), 기존 게시물 수정 하기(update)
-자원에 대하여 메시지를 주고 받을때, JSON과 같은 형태로 데이터를 표현한다.
-서버가 데이터를 어떻게 관리하는지보다 표현자체에 더 중점을 둔다.
각 요청과 응답은 자기 자신을 해석하기 위한 충분한 정보를 포함하여야 한다
-즉 JSON 형태로 데이터를 보냈다면, 해당 내용임을 요청에 명시되어야 한다.
-Content-type 헤더에 application/json
REST API를 만드는것이 아니라 RESTful 한 모습을 목표로 API를 제작
1. URL 구성할때 URL이 자원을 논리적이게 잘 표현할수 있도록
2. 자원에 적용할 작업을 HTTP Method로 구분할수 있도록
RM Model Level 2 정도
URL과 Method
작업을 위한 URL이 자원을 식별할수 있도록 URL을 구성
- /articles: 전체 글들을에 대해서 작업하기 위한 URL
- /articles/{id}: 어떤 특정 글에 대해서 작업하기 위한 URL
자원에 어떤 행동을 할지 HTTP Method를 통해 구분한다.
-CREATE -> 새로운 자원 생성(POST)
-READ -> 자원 조회(GET)
-UPDATE -> 자원 수정(PUT)
-DELETE -> 자원 삭제(DELETE)
