REST
REST(Representational State Transfer)는 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처다. REST는 자원지향구조(ROA: Resource Oriented Architecture)로 웹 컨텐츠, DB의 내용 등 모든 정보를 하나의 자원으로 인식한다. 그리고 각 자원에 고유한 URI(Uniform Resource Identifier)를 부여함으로써 해당 자원에 대한 CRUD 작업을 HTTP 기본 명령어인 POST, GET, PUT, DELETE를 통해서 처리한다.
| HTTP method | CRUD | SQL |
|---|---|---|
| POST | Create | INSERT |
| GET | Read | SELECT |
| PUT | Update | UPDATE |
| DELETE | Delete | DELETE |
1. 구성
- Resource(자원): URI
- Verv(행위): HTTP method
- Representations
2. 특성
Uniform Interface
통일된 인터페이스를 통해 다양한 기술(Python, PHP, C#, Ruby, java 등)을 플랫폼(iOS, Android, Mac 등)에 상관없이 사용할 수 있다. Uniform Interface는 크게 4가지로 설명된다.
- Resource Identifier (URI)
일반적으로 리소스는 서비스 또는 정보를 제공하는 모든 것들을 뜻하며 특정 주소인 URI를 가져야 한다. - Resource Representation
Client-Server 구조에서 리소스를 직접 주고 받는 것이 아닌 그 리소스에 대한 상태나 정보를 설명(대표)하는 Representation을 주고 받는다. 해당 Representation의 형태는 content-type(text/html, application/json, application/xml 등)으로 결정된다. - Self-Descriptive message & API
REST는 State를 유지하지 않으므로 Client-Server 간 메시지 전달 시 자신에 대한 State 정보를 설명해야 한다. - HASTOEAS
Hypermedia As The Engine Of Application State. HTTP response에 다음 Action이나 관계되는 리소스에 대한 HTTP 링크를 함께 제공한다. 예를들어 페이징처리시 이전 페이지, 이후 페이지에 대한 링크를 함께 제공한다.
Stateless
REST의 가장 대표적인 특징이다. 작업을 위한 상태정보(세션, 쿠키 등)를 따로 저장하고 관리하지 않는다. 즉 들어오는 요청만을 단순히 처리한다. 이로 인해 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다. 단, 클라이언트는 API key 또는 token과 같은 자신을 구분하기 위한 정보를 서버에게 충분히 전달해야 한다.
Cacheable
REST는 HTTP 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 사용 가능하다. 일반적인 서비스 시스템에서 많게는 80%가량의 트랜잭션이 Select와 같은 조회 트랜잭션인 것을 고려하면, HTTP의 리소스들을 웹캐시 서버 등에 캐싱하는 것은 용량이나 성능 면에서 많은 장점을 가지고 올 수 있다.
Client-Server 구조
Client와 Server에서 개발해야 할 내용이 명확하게 구분되고 서로간 의존성이 적다.
Self-descriptiveness
REST API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다. 또한 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조이다.
대부분의 REST 기반의 OPEN API들이 API 문서를 별도로 제공하고 있지만, 디자인 사상은 최소한의 문서만으로도 API 자체를 이해하는 것이다.
3. RESTful API Design
REST API 설계 시 다음 두 가지 규칙을 지켜야 한다.
- URI는 정보의 자원을 표현해야 한다.
- 자원에 대한 행위는 HTTP method(GET, POST, PUT, DELETE)로 표현된다.
리소스명은 동사보다는 명사를 사용하는 것이 좋다. 예를 들자면 GET /rules/delete/{ruleId}는 RESTful하지 않은 표현이다. delete는 행위를 표현하기 때문이다. 이를 표현하기 위해 DELETE /rules/{ruleId}와 같이 '삭제'라는 행위를 HTTP method로 표현한다.
또한 아래의 주의사항을 참고하여 API를 설계하는 것이 좋다.
- 될 수 있으면 소문자를 사용
- 하이픈(-)은 URI 가독성을 높이는데 사용
- 확장자를 사용하지 말 것
Reference
댓글