💡REST API와 RESTful API에 대하여 정리하였습니다.
REST
- Representational State Transfer의 약자로 자원을 이름(자원이 표현)으로 구분해 해당 자원의 상태(정보)를 행위로 주고 받는 것들을 의미합니다.
- 자원의 표현에 의한 상태 전달
- [자원] : 해당 소프트웨어가 관리하는 모든 것으로 문서, 그림, 데이터, 소프트웨어 자체 등
- [표현] : 그 자원을 표현하기 위한 이름
- [상태 전달] : 데이터가 요청되는 시점에 자원의 상태를 전달하며, 주로 JSON 활용
- REST는 기본적으로 웹의 기존 기술과 HTTP를 활용하여 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.
- REST는 네트워크에서 Client와 Server 사이의 통신 규약을 가지는 아키텍처입니다.
어떤 자원에 대해 CRUD 연산을 수행하기 위해 URI로 Method를 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태로 표현될 수 있습니다.
URI vs URL
- [URI] : Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열
- [URL] : Uniform Resource Locator로 인터넷 상 자원의 위치
- 즉 URI는 URL을 포함하고 있습니다.
자원 : URI
- 모든 자원은 교유한 ID가 존재하고, 이 자원은 Server에 저장됩니다.
- HTTP URI로 자원을 구분하며, Client는 URI를 통해 자원을 저장하고 해당 자원을 상태에 대한 조작을 서버에 요청할 수 있습니다.
행위 : Method
- HTTP 프로토콜의 Method인 CRUD를 제공합니다.
표현 : Representation of Resource
- Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있습니다.
REST 원칙
Statelessness
- 각 요청은 독립적이며, 서버는 요청 간의 상태를 유지하지 않습니다.
Client - Server
- 클라이언트 - 서버 구조를 가지며, 각 구조가 독립적으로 동작합니다.
- 자원을 가지는 쪽이 Server, 요청하는 쪽이 Client가 됩니다.
- REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지며, Client는 사용자 인증이나 context( 세션, 로그인 정보) 등을 직접 관리하고 책임집니다.
- 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄일 수 있습니다.
Cachability
- 응답은 캐시 가능해야 하며, 이를 명시적으로 지정해야 합니다.
- 대량의 요청을 효율적으로 처리할 수 있습니다.
Layered System & Uniform Interface
- 클라이언트는 중간 서버나 프록시를 모르게 되며, 다중 계층으로 구성될 수 있습니다.
- 모든 리소스에 대해 동일한 인터페이스를 제공합니다.
REST API
- REST API란 REST의 특징을 기반으로 서비스 API를 구현한 것입니다.
- 가장 큰 특징은 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능한 것입니다.
REST API 설계 가이드
- URI는 정보의 자원을 표시해야 합니다.
- 자원에 대한 행위는 HTTP Method인 CRUD로 표현됩니다.
- 행위에 대한 정보는 URI에 포함시키지 않습니다.
- URI는 명사를 사용하며, 슬래시를 통해 계층 관계를 표현합니다.
- 마지막 문자는 슬래시를 포함하지 않으며, 밑줄( _ ) 대신 하이픈( - )을 활용합니다.
- URI는 소문자로 구성하며, 파일 확장자를 포함하지 않습니다.
REST API vs RESTful API
- RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API이며, REST의 원리를 잘 따르는 시스템을 뜻합니다.
- HTTP 메서드와 URI를 잘 설계하고, 상태를 유지하지 않으며, REST의 모든 원칙을 충실이 따르는 API입니다.
- 가장 중요한 점은 URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시해야 RESTFul API를 설계할 수 있다는 것 입니다.