[네트워크] REST와 RESTful API

REST는 표현 상태 전송을 나타낸다. API(응용 프로그래밍 인터페이스)가 작동하는 방식을 설정하는 제약 조건 집합이다. API가 RESTful이면 API가 REST 아키텍처를 준수한다는 의미다. 간단히 말해서 API에 관한 한 REST와 RESTful 사이에는 차이가 없다. REST는 제약 조건의 집합이다. RESTful 은 이러한 제약 조건을 준수하는 API를 나타낸다. 웹 서비스, 응용 프로그래밍 및 소프트웨어에서 사용할 수 있다.

📌 REST(Representational State Transfer)

REST의 정의
- Representational State Transfer (대표적인 상태 전달)의 약자
- 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
- REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나다.

구체적인 개념
- HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
- 즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고, HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미한다.
- 웹 사이트의 이미지, 텍스트 DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL을 부여한다.

REST 특징
- Server-Client(서버 클라이언트 구조)
- Stateless (무상태성)
(cookie 를 이용해 session을 서버에 저장했다면, rest는 header에 token을 넣어 인증하고 세션을 저장하지 않는다)
- Cacheable(캐시 처리 가능)

장단점
- 장점
1. 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해 준다.
2. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
3. HTTP 프로토콜 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
- 단점
1. 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL 보다 Header 값이 어렵게 느껴진다.
2. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
- PUT, DELETE를 사용하지 못하는 점 (form의 경우 <input type-"hidden" name="_method" />)로 줄 수 있다.)
- pushState를 지원하지 않는 점 ( history.pushState - 뒤로 가기 )
- URL를 통한 ServerSide Rendering 방식을 이용하게 된다면
- 메인 페이지 -> 보드 1 페이지 -> 보드 5 페이지 클릭 -> 뒤로 가기 -> 보드 1 페이지
- REST 방식을 이용하게 된다면
- 메인 페이지 -> 보드 1 페이지 -> 보드 5 페이지 클릭 -> 뒤로 가기 -> 메인 페이지

REST 가 필요한 이유
- 애플리케이션 분리 및 통합 (MSA = Micro Soft Service Application)
- 다양한 클라이언트의 등장
- 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다
- MSA (Micro Service Application) 분산 서비스와 관련되어있다 ( api call을 통한 데이터 처리 )

- REST 구성 요소
A. 자원 (Resource) URI
- 모든 자원에 고유한 id 가 존재하고, 이 자원은 Server에 존재한다
- 자원을 구별하는 id는 'localhost:8080/user/:userId'와 같은 HTTP URI이다
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다

B. 행위 (Verb) : Http Method
- HTTP 프로토콜의 Method를 사용한다
- HTTP 프로토콜은 GET, POST, PUT, DELETE, HEAD와 같은 메서드를 제공한다

C. 표현 (Representation of Resource)
- Client 가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답 표현(Representation)을 보낸다
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어질 수 있다
- 옛날에는 XML 이였지만 현대에는 JSON으로 표현하고 있다

📌 REST API (Representational State Transfer Application Programming Interface)

- API는 해당 애플리케이션을 제어할 수 있게 해주는 중간 인터페이스(연결점)
- 예를 들어 키보드라는 인터페이스를 통해 하드웨어에 입력을 해주는 기능을 해주는 것과 같다.
- 영화 조회 서비스 API 를 통해 특정 명령만 내리면 해당 어플리케이션이 그에 맞는 기능을 수행해준다.

정의
- REST 를 기반으로 서비스 API 를 구현한 것
- 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.

특징
- REST 기반으로 시스템을 분산해 확장성과 재사용을 높여 유지보수 및 운용을 편리하게 할 수 있다
- REST 는 HTTP 표준을 기반으로 구현하므로, HTTP 를 지원하는 프로그래밍언어로 클라이언트, 서버를 구현할 수 있다

기본 설계 규칙
A. URI는 자원(Resource) 를 표현해야 한다
1. resource 는 명사
2. 소문자 복수형
3. GET /members/1
B. 자원에 대한 행위는 HTTP Method (GET, PUT, PATCH, DELETE, POST 등)으로 표현한다
1. URI 에 HTTP Method 가 들어가면 안된다
- GET /members/delete/1 -> DELETE /members/1
2. 어떤 행위(Behavior)나 행동(Action) 에 관해서 동사 표현이 들어가면 안된다
- GET /members/insert/2 -> POST /members/2
- GET /members/show/1 -> GET /members/1

REST API 설계 규칙
- 슬래시 구분자(/) 는 계층 관계를 나타내는데 사용된다
- URI 마지막 문자로 슬래시(/) 를 포함하지 않는다
- 대소문자 구분으로서 kebab case 형식을 사용한다 (team-board)
- 밑줄(_ )은 URI에 사용하지 않는다.
- 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
-URI 경로에 대문자 사용은 피하도록 한다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
- 파일확장자는 URI에 포함하지 않는다.
- REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
- Accept header를 사용한다.
- Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
- Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
- 리소스 간에는 연관 관계가 있는 경우
- /리소스명/리소스 ID/관계가 있는 다른 리소스명
- Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
- :id는 하나의 특정 resource를 나타내는 고유값
- Ex) student를 생성하는 route: POST /students
- Ex) id=12인 student를 삭제하는 route: DELETE /students/12

📌 RESTful

- RESTful의 개념
RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
- RESTful의 목적
이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현하실 필요는 없습니다.
- RESTful 하지 못한 경우
ex) CRUD 기능을 모두 POST로만 처리하는 API
ex) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)