dev_hun
2022. 12. 16. 16:35
2022. 12. 16. 16:35
REST(REpresentational State Transfer)란?
- REST(REpresentational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다. 로이 필딩(Roy Fielding)은 HTTP를 목적에 맞게 그리고 보다 실용적이게 사용하기 위해 REST 아키텍쳐를 정의하였습니다.
CRUD Operation이란?
- CRUD는 대부분의 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create, Read, Update, Delete를 일컫는 말입니다.
CRUD Operation과 HTTP Method
| CRUD |
HTTP Method |
| Create |
POST |
| Read |
GET |
| Update |
PUT, PATCH |
| DELETE |
DELETE |
- CRUD Operation과 HTTP Method를 맵핑하면 위와 같은 표로 구성됩니다.
REST 구성 요소
1. 자원(Resource) : HTTP URI
2. 자원에 대한 행위(Verb) : HTTP Method
3. 자원에 대한 행위의 내용(Representations) : HTTP Message Payload
REST 특징
1. Server-Client 구조
- REST API를 이용하여 서로간의 의존성을 줄인 독립적인 Server, Client 구조를 가집니다.
2. Stateless
- HTTP 프로토콜을 기반으로 하기 때문에 서버가 클라이언트의 상태를 보존하거나 기억하지 않습니다.
3. Cacheable
- HTTP 프로토콜을 그대로 사용하기 때문에 HTTP의 기능인 캐싱 기능을 사용할 수 있습니다.
4. Uniform Interface
- identification of resources(자원에 대한 식별) :
URI를 통해 자원을 식별할 수 있어야 합니다.
- manipulation of resources through representations(표현을 통한 자원에 대한 조작) :
표현된 자원에 대해서 조작할 수 있어야 합니다.
- self-descriptive messages(자기 서술적 메시지) :
자기 서술적 메시지로서 요청, 응답 메시지만을 가지고 해석할 수 있어야 합니다. 이러한 해석을 만족하려면 Host 헤더에 Host 이름 또는 IP를 기재해야 하고, Media Type을 정확하게 표기해야 합니다.
HTML은 각 태그마다 목적이 명확하게 명세화가 되어 있어 self-descriptive message를 만족하지만, json 같은 경우에는 파싱에 대한 규칙만 정해져 있기 때문에 application/json 만으로는 self-descriptive message를 만족할 수는 없습니다.
self-descriptitive message를 만족하려면 IANA에 Media Type을 등록하던가 link 헤더에 데이터에 대한 명세를 profile로 등록해서 self-descriptitive message을 만족할 수 있습니다.
- hypermedia as the engine of application state(HATEOAS) :
Hypermedia를 통해서 애플리케이션의 상태 전이 또는 자신에 대한 정보를 확인할 수 있는 정보가 담겨야 합니다.
HATEOAS를 만족할 경우 서버는 link를 언제든지 마음대로 바꿀 수 있습니다. 즉, 클라이언트는 고정된 link가 아닌 서버에서 받은 동적 link를 통해서 상태 전이를 할 수가 있습니다.
HATEOAS를 만족하려면 link 헤더를 사용하던가, 또는 body에 link에 대한 정보를 넣고 이에 대한 명세를 link 헤더에 profile로 등록하여 만족시킬 수 있습니다.
5. Layered System
- API 서버는 순수 비지니스 로직을 수행 합니다.
- 클라이언트는 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지 인지 할 수 없으며, 이를 통해 중간 서버 (로드 밸런싱, 공유 캐시)를 제공함으로써 시스템 규모 성능 및 확장성 향상 됩니다.
6. Code on demand (optional)
- 서버가 클라이언트에게 코드를 응답해주면, 클라이언트는 응답 코드를 실행 할 수 있습니다. ex) JavaScript
REST의 장점
- HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능합니다.
- Client와 Server간의 의존성이 없기 때문에 독립적인 업데이트가 가능합니다.
- REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
REST의 단점
- 표준이 존재하지 않아 올바른 REST API 작성 및 관리의 어려움이 있습니다.
REST API란?
- REST API란 REST 아키텍쳐 스타일을 따르는 API를 말합니다.(아키텍쳐 스타일은 제약 조건들의 집합을 의미합니다.)
RESTful이란?
- RESTful이란 REST API의 설계 규칙을 올바르게 지킨 시스템을 말합니다. RESTful 시스템을 잘 지킨 서비스는 URI와 HTTP Method만을 가지고 어떤 요청을 하는지 파악하기 용이합니다.
REST API 설계 시 주의사항
- REST API를 올바르게 설계하기 위해서는 아래와같은 규칙을 지켜야합니다.
1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용해야 합니다.
2. 슬래시( / )로 계층 관계를 표현합니다.
3. URI 마지막에는 슬래시(/)를 포함하지 않습니다.
4. 언더바(_) 대신 하이픈(-)을 사용합니다.
5. 파일 확장자는 URI에 포함하지 않습니다.
6. 자원에 대한 행위를 URI에 포함하지 않습니다.
7. REST API로 요청한 데이터는 HTML,CSS가 아닌 JSON 또는 XML 형식으로 반환합니다.
8. HTTP 응답 상태 코드 사용한다
- 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.
- 2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.
- 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.
- 4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
- 5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.
REST API 예외상황
- GET, DELETE Method는 body를 사용할 수 없기 때문에 개발하는데 있어서 예외적으로 POST와 같은 다른 Method를 사용해야 하는 경우가 있습니다.
- 클라이언트 요청에 대한 성공과 오류에 대한 메시지를 HTTP 상태 코드를 사용하여 소통을 합니다.