REST란?
REST는 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다. 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
CRUD Operation
- Create : 생성(POST)
- Read : 조회(GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
- HEAD: header 정보 조회(HEAD)
REST 구성 요소
- 자원(Resource): URI
- 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
- 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
- Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
- 행위(Verb): HTTP Method(GET, POST, PUT, DELETE 등)
- 표현(Representation of Resource)
- Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
- REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
- JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
REST 특징
1. Server-Client(서버-클라이언트 구조)
REST API 디자인에서 클라이언트와 서버 애플리케이션은 서로 완전히 독립적이어야 한다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI이다. 다른 방법으로는 서버 응용 프로그램과 상호 작용할 수 없다. 마찬가지로 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 클라이언트 애플리케이션을 전달하는 것 외에는 클라이언트 애플리케이션을 수정해서는 안 된다.
2. Stateless(무상태)
REST API는 Stateless 상태이다. 즉, 각 요청은 처리에 필요한 모든 정보를 포함해야 한다. REST API에는 서버 측 세션이 필요하지 않다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없다.
3. Cacheable(캐시 처리 가능)
가능하다면 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 한다. 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 한다. 목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것이다.
4. Layered System(계층화)
REST API에서 호출과 응답은 서로 다른 계층을 거친다. REST API는 클라이언트나 서버 모두 최종 애플리케이션이나 중개자와 통신하는지 여부를 알 수 없도록 설계해야 한다.
5. Code-On-Demand(optional)
REST API는 일반적으로 정적 리소스를 보내지만 어떤 경우에는 응답에 실행 가능한 코드가 포함될 수도 있다. 이러한 경우 코드는 요청 시에만 실행되어야 한다.
6. Uniform Interface(인터페이스 일관성)
동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일하게 표시되어야 한다. REST API는 사용자의 이름이나 이메일 주소와 같은 동일한 데이터가 하나의 URI(Uniform Resource Identifier)에만 속하도록 해야 한다. 리소스는 너무 커서는 안 되지만 클라이언트에 필요할 수 있는 모든 정보를 포함해야 한다.
REST API란?
REST API(REpresentational State Transfer)는 웹상에서 사용되는 여러 리소스를 HTTP URI로 표현하고, 해당 리소스에 대한 행위를 HTTP Method로 정의하는 방식을 말한다.
API(Application Programming Interface)란
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
REST API의 설계 가이드
- 리소스에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE)로 표현한다.
- /(슬래시)는 계층 관계를 나타낼때 사용한다.
- URI 마지막 문자에 /(슬래시)를 사용하지 않는다.
- URI에 _(underscore)는 사용하지 않도록 한다. 또한 영어 대문자보다는 소문자를 쓴다.
그리고 가독성을 위해서 긴 단어는 잘 사용하지 않는다. - URI에 동사는 GET, POST와 같은 HTTP Method를 표현하기 때문이다.
동사가 아니라 명사를 사용한다. - URI에 파일의 확장자(예를들어 .json , .JPGE)를 포함 시키지 않는다.
REST API 설계 예시
| CRUD | Http verbs | Route |
|---|---|---|
| resource들의 목록을 표시 | GET | /resource |
| resource 하나의 내용을 표시 | GET | /resource/{id |
| resource를 생성 | POST | /resource |
| resource를 수정 | PUT | /resource/{id} |
| resource를 삭제 | DELETE | /resource/{id |
참고 응답상태 코드
- 1xx : 전송 프로토콜 수준의 정보 교환
- 2xx : 클라어인트 요청이 성공적으로 수행됨
- 3xx : 클라이언트는 요청을 완료하기 위해 추가적인 행동을 취해야 함
- 4xx : 클라이언트의 잘못된 요청
- 5xx : 서버쪽 오류로 인한 상태코드
RESTful이란?
RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다. REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTful의 목적
API를 RESTful 하게 만들어서 API의 목적이 무엇인지 명확하게 하기 위해 RESTful 함을 지향 한다.
참조
