RESTful API
- API 란?
애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 때때로 API는 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(호출)와 생산자에게 필요한 콘텐츠(응답)를 구성합니다.
- REST 란?
- REST API 에서 REST 는 Representational State Transfer(표현 상태 전이)의 약자로, 소프트웨어 프로그램 아키텍처의 한 방식이다.
- 즉, 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.
- RESTful API 란?
RESTful API는 HTTP 통신에서 자원과 method를 명시하여 해당 자원에 대한 CRUD 정보를 나타내는 것을 말합니다.
Method의 종류로는 get, post, put, delete, patch 등을 사용하여 자원에 대한 요청을 보내고, 서버는 이러한 요청에 응답을 제공합니다.
특징(RESTful 기준)
- RESTful api 의 특징으로는
무상태성
, 캐시 가능성
, 계층화
, 인터페이스 일관성
, 자체 표현 메시지
총 5가지가 있다.
- 무상태성(Stateless)
- 서버는 클라이언트의 상태 정보를 저장하지 않으며, 요청에 대한 응답만 전달한다.
- 캐시 가능성(Cacheable)
- 응답은 캐시할 수 있어야 하며, 캐시를 사용함으로써 서버의 부하를 줄일 수 있다.
- 계층화(Layered System)
- 클라이언트는 서버와 직접적인 통신을 하지 않고, 중간에 프록시 서버 등 다른 시스템을 거칠 수 있다.
- 자원의 표현과 자원에 대한 조작(생성, 조회, 수정, 삭제)에 대한 인터페이스가 일관성 있게 설계되어야 합니다.
- 자체 표현 메시지(Self-descriptive Messages)
- 요청과 응답은 스스로 설명할 수 있는 메시지여야 합니다.
장단점
- 장점
- HTTP 프로토콜의 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- Hypermedia API 의 기본을 충실히 지키면서 범용성을 보장한다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 쉽게 파악할 수 있다.
- 서버와 클라이언트의 역할을 명확하게 분리한다.
- 단점
- HTTP 메소드 형태가 제한적이다.
- 브라우저를 통해 테스트할 일이 많은 서비스라면, 쉽게 고칠 수 있는 URL 보다
Header 정보의 값을 처리해야하므로 전문성이 요구된다.
- 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.
설계 방법
- URI 는 동사보다 명사를, 대문자보다는 소문자를 사용한다.
잘못된 예시 > http://flix.com/Running
올바른 예시 > http://flix.com/run
- 마지막에 슬래시(/)를 포함하지 않는다.
잘못된 예시 > http://flix.com/Running/
올바른 예시 > http://flix.com/run
- 언더바 대신 하이픈을 사용한다.
잘못된 예시 > http://flix.com/test_one
올바른 예시 > http://flix.com/test-one
- 파일 확장자는 URI에 포함하지 않는다.
잘못된 예시 > http://flix.com/photo.jpg
올바른 예시 > http://flix.com/photo
- 행위를 포함하지 않는다.
잘못된 예시 > http://flix.com/delete-post/1
올바른 예시 > http://flix.com/post/1
결론 :
RESTFUL이란 REST의 원리를 따르는 시스템을 의미한다.
하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다.
REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며
모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.
참고자료_1
참고자료_2