1. REST API
- REST API 에서 REST는 Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식(해당 자원의 상태를 주고 받는 모든 것)을 의미
- 월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
REST의 구체적인 개념
- HTTP URI를 통해 자원을 명시하고, HTTP Method (POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD OPERATION을 적용하는 것을 의미한다.
- 즉, REST는 자원 기반의 구조 (ROA: Resource Oriented Architecture) 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
- 웹의 모든 자원에 고유한 ID인 HTTP URI 를 부여한다.
REST의 구성 요소
- Resource
서버는 Unique한 ID를 가지는 Resource를 가지고 있으며, 클라이언트는 이러한 Resource에 요청을 보냅니다. 이러한 Resource는 URI에 해당합니다.
- Method
서버에 요청을 보내기 위한 방식으로 GET, POST, PUT, PATCH, DELETE가 있습니다. CRUD 연산 중에서 처리를 위한 연산에 맞는 Method를 사용하여 서버에 요청을 보내야 합니다.
- Representation of Resource
Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있습니다.
JSON, XML을 통해 데이터를 주고 받는 것이 일반적입니다.
REST의 특징
Server-Client (서버-클라이언트 구조)
- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됩니다.
- REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고,
- Client는 사용자 인증이나 context( 세션, 로그인 정보 ) 등을 직접 관리하고 책임집니다.
- 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄입니다.
Stateless (무상태)
- HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖는다.(작업을 위한 상태정보를 따로 저장하고 관리하지 않는다)
- Client의 context를 Server에 저장하지 않습니다.
즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해집니다. - Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.
3-1 각 API 서버는 Client의 요청만을 단순 처리합니다.
3-2 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안됩니다. ( DB에 의해 바뀌는 것은 허용 )
3-3 Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아집니다.
Cacheable (캐시 처리 기능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있습니다.
즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있습니다.
HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현합니다. - 대량의 요청을 효율적으로 처리할 수 있습니다.
Layered System (계층 구조)
- Client는 REST API Server만 호출합니다.
- REST Server는 다중 계층으로 구성될 수 있습니다.
보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있습니다.
Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있습니다.
하지만 Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없습니다.
Uniform Interface (인터페이스 일관성)
- URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미합니다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling(느슨한 결함) 형태를 갖습니다.
즉, 특정 언어나 기술에 종속되지 않음
Self-Descriptiveness (자체 표현)
- REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조
REST API의 특징
- 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
- REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
- 즉, REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.
REST API의 설계 규칙
- 소문자를 사용한다.
- 언더바(_) 대신 하이픈(-)을 사용한다.
- 마지막에 슬래시(/)를 포함하지 않는다.
- 행위를 포함하지 않는다.
- 파일 확장자는 URL에 포함시키지 않는다.
- 자원에는 형용사, 동사가 아닌 명사를 사용하며, 컨트롤 자원은 예외적으로 동사를 허용한다.
RESTful이란?
- RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
- ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다. - RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
- 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTful의 목적
- 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
RESTful 하지 못한 경우
- Ex1) CRUD 기능을 모두 POST로만 처리하는 API
- Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)
출처:
https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80
https://dev-coco.tistory.com/97#REST%--API%EC%-D%--%--%EC%--%A-%EA%B-%--%--%EA%B-%-C%EC%B-%--
https://mangkyu.tistory.com/46
https://dev-cool.tistory.com/32
