Restful api를 사용하는 이유는?
> 일관적인 컨벤션을 통한 API의 이해도 및 호환성 높이는 것
(요청 메시지만 봐도 무엇을 원하는지 파악 가능)
> 개발자 간의 협업 용이 + 새로운 개발자가 기존의 API를 빠르게 이해하고 적용하도록 도와줌
RESTful API
➡️인터넷 식별자 URI (Uniform Resource Identifier)와 HTTP를 기반으로
브라우저간 호환성이 좋은 JSON 형식을 주로 사용함
➡️ (중요 특성) 각 요청이 어떤 정보나 동작을 위한 것인지 그 자체로 추론이 가능함
➡️ HTTP Method ( POST, GET , PUT, DELETE, PATCH ) 를 활용해서 해당 자원에 대한 CRUD 적용하여 핸들링 가능
➡️REST API는 HTTP 요청을 할때, 어떤 URI에 어떤 method를 사용할지에 개발자들 사이에 널리 지켜지는 약속
01. REST란?
RE : Representational / S : State / T : Transfer
"어떤한 상태를 주고 받는다"
✅ 자원의 이름(표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것
✅ 웹의 기존 기술 + HTTP 프로토콜을 그대로 활용 => 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
02. REST 구성요소
1️⃣ 자원 : URI
2️⃣ 행위 : HTTP Method (GET, POST, PUT, DELETE, PATCH)
3️⃣ 표현 : JSON 혹은 XML 데이터 주고받기 (일반적)
* 클라이언트 (accept 필드로 지정가능) : 원하는 자원과 표현으로 요청 & 서버: 자원의 표현으로 응답
* 요청 HEADER (text/html, image/png)
03. REST 특징
1️⃣ Uniform Interface
* 모든 리소스에 대하여 동일한 인터페이스를 사용함
(GET은 리소스 정보 가져오기 / POST는 새 리소스 사용하기)
2️⃣ Stateless (무상태)
* HTTP 프로토콜 = Stateless Protocol => REST 역시 무상태성
3️⃣ Cacheable (캐시가능)
* 응답을 캐시할 수 있도록
4️⃣ Layered System (계층형 구조)
* Client는 REST API Server만 호출함
* REST Server는 다중 계층으로 구성 가능
5️⃣ Server - Client
* Server : API 제공 + 비즈니스 로직 처리 및 저장
* Client : 사용자 인증 + content(세션, 로그인 정보) 관리
* 서로 간 의존성이 줄어듦
6️⃣Code-On-Demand (optional)
04. REST 장단점
장점
* HTTP 프로토콜 인프라를 사용하기에 별도의 인프라 구축 필요 없음
* HTTP 표준 프로토콜 사용 => 모든 플랫폼에서 사용 가능
* 서버와 클라이언트의 역할 명확하게 분리
단점
* 표준이 존재 x
* 사용가능한 메소드 4가지
05. REST 필요한 이유
* 애플리케이션 분리 및 통합
* 다양한 클라이언트의 등장
* 최근의 서버 프로그램은 다양한 브라우저 + 모바일 디바이스에서도 통신 가능해야함
06. REST API 설계 규칙
RESTFUL : REST 아키텍처 스타일로 요청과 응답을 하는 API
API : 두 애플리케이션이 서로 통신하는 방법을 정의한 것
( REST API : REST 기반으로 서비스 API 구축하는 것)
1️⃣ URL는 정보의 자원을 표현하기
* resource는 명사, 소문자 사용 / 도큐먼트 이름 : 단수 명사 / 컬렉션 & 스토어 이름 : 복수명사
* get/Member/1 ➡️ get/member/1
2️⃣ 자원에 대한 행위는 HTTP method로 표현
* URI에 HTTP method 사용 x
* URI에 동사표현 x (get/members/show/1 ➡️ get/members/1 )
3️⃣ 슬래시 구분자 (/)는 계층관계를 나타날 때 사용하기 + 마지막 문자로 슬래시 (/) 사용 금지
4️⃣ 언더바(_) 대신 하이픈(-) 사용
끝.