REST API

REST API

1. REST의 정의

자원(Resource)의 표현(Representation) 에 의한 상태 전달

REST란 Representational State Transfer 의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든것을 의미합니다.

즉, 정리하자면

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는것을 의미합니다.
4. 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다.

자원: 문서, 그림, 데이터 등 소프트웨어가 관리하는 모든 것
자원의 표현: 그 자원을 표현하기 위한 이름

CRUD Opertaion 이란
CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로
REST 에서의 CRUD Operation 동장 예시는 다음과 같습니다.

Create : 데이터 생성 (Post)
Read : 데이터 조회(Get)
Update : 데이터 수정(Put,Patch) 
Delete : 데이터 삭제(Delete)

---

2.REST의 구성 요소

2.1. 자원(Resource)

REST에서의 자원(Resource) 은 URI 로 정의됩니다.

Resouce라는 것은 처리되는 대상을 의미하며, JSON, XML 문서가 될 수도 있고, jpg 파일과 같은 이미지, mp4와 같은 비디오가 될 수도 있습니다.
이러한 Resource들은 URI에 의하여 표현되는데, URI 란, Uniform Resource Idetifier 의 약자로, 우리말로 하면 통합 자원 식별자 로 볼 수 있습니다.
URI 는 특정 자원의 위치를 나타내는 유일한 주소로, 인터넷 프로토콜(HTTP) 혹은 파일 전송 프로토콜(FTP)등과 함께 사용하는 경우가 많습니다.

즉, URI는 인터넷 자원을 나타내는 고유 식별자 이기 때문에, 인터넷 상에서 특정 자원을 나타내는 유일한 주소로, 식별을 위하여 중복 된 값을 가질 수 없습니다.

URI의 구조

scheme:[//host[:port]][/path][?query][#fragment]

Example) http://123.456.789.12:1234/test?abc=dfe

scheme(스키마): 요청하는 요청 형식을 지정하는 것

예를 들어 scheme 부분에 ftp를 사용하면 ftp 통신, http를 사용하면 http통신이 되는 식입니다.
즉, scheme 부분은 7계층의 프로토콜을 지정하는 부분입니다.
웹 통신은 HTTP를 통하여 하기 때문에 HTTP,HTTPS를 사용하는 것

host(ip주소)[:port] 웹 서버의 호스트 명으로, 도메인 명 또는 IP주소로 표현됩니다.
보통 port 번호의 경우 생략되며, http의 경우 80, https의 경우 443이며, 지정하는 방법에 따라 다른 port로도 지정이 가능하며, 다른 포트로 지정 한 경우 이 포트를 가리기 위해선 Reverse Proxy등의 특수한 방법이 필요합니다.
또한 보통은 IP주소 대신 도메인 주소를 사용하는데, IP주소를 도메인 주소로 사용이 가능하게 해주는 것이 DNS 서버 입니다.

path: 파일이나 애플리케이션 경로를 의미합니다.

query: 질의 문자열로, 앰퍼샌드(&)로 구분된 키=값 쌍 형식으로 표현 합니다.
보통 전달하는 데이터 정도로 생각하시면 됩니다.

---

2.2. 메소드 (Method, 행위(verb))

REST API에서는 리소스에 대한 행위가 일관되게(Uniform) 정의됩니다.
즉, REST API로 다루는 대상 리소스가 문서든, 이미지든, 비디오든 상관없이 같은 메소드에 의해 다뤄집니다. REST API에서 사용되는 메소드는 HTTP Method로 POST, GET, PUT, PATCH, DELETE 등이 있습니다. 이들은 각각 CRUD에 다음과 같이 매핑될 수 있습니다.

HTTP Method	CRUD 연산
POST	CREATE
GET	READ
PUT	UPDATE / REPLACE
PATCH	UPDATE / MODIFY
DELETE	DELETE

위 테이블은 HTTP 메소드에서 일반적으로 사용되는 CRUD 연산과 대응 시켰으며, 이 외에도 몇가지 더 존재하고 있습니다.

---

2.3. 표현 (Representation)

HTTP 메소드와 URI만으로는 원하는 내용을 모두 표현할 수 없습니다.
예를 들어 새로운 유저를 생성하라는 REST API를 만든다고 가정했을 때,
POST http://21V.dev/users/newuser
Host에 있는 users 에 newuser라는 사용자를 추가하는 REST API입니다.

사용자의 특성에는 이름뿐만 아니라 성별, 주소, 나이 등의 다양한 특성이 존재하는데, 새로운 유저를 입력할 때 이러한 정보들이 필요하게 되고, 이는 XML이나 JSON, YAML, TEXT, RSS 와 같은 다양한 표현 언어를 이용하게 됩니다. 이러한 HTTP 메소드의 정보 표현 부분을 메소드 바디(Body) 혹은 Payload 라고 합니다.

위에서 명시한 것과 같이 이 Body, Payload 부분은 여러가지 표현 언어로 정의될 수 있습니다. 이 때, REST API의 HEADER 부분에 Content-Type: application/json 같은 헤더를 추가하여 Payload를 해석할 수 있게 명시 해주어야 합니다.

POST http://21V.dev/users Content-Type: applcation/json

{
    "username" : "newusers",
    "age" : "20",
    "address" : "Asia/Seoul"
}

이와 같은 형태로 Post Method에 Payload를 붙여서 요청할 수 있습니다.

---

3. REST API의 특징, 장점

1. Uniform
   • REST API는 리소스에 상관없이 동일한 API 메소드를 갖습니다.
   • 즉, 이미지 리소스에 대한 처리와 문서 리소스에 대한 처리가 일관 된 형태로 요청 됩니다.
2. Stateless
   • REST API를 제공하는 서버측에서 수행의 문맥(Context)을 저장하지 않습니다.
   • 즉, 이전에 어떤 요청을 했는지 같은 정보를 저장하지 않고, 각 REST API는 독립적으로 처리 됩니다. 문맥 처리가 필요하다면 클라이언트가 자체적으로 관리를 해야하며, 세션 정보를 서버에 유지하지는 않습니다.
3. Cacheable
   • HTTP 프로토콜을 사용하기 때문에 기존 웹 인프라를 그대로 사용 가능합니다.
   • 즉, 웹 브라우저에서 HTTP 캐시를 이용하는 등의 동작이 그대로 이용 가능 합니다. 같은 URI에 대한 요청이 여러번 있을 때, URI 리소스를 매번 서버로 요청 하지 않고, 클라이언트의 HTTP 캐시에서 미리 가져온 정보를 반환합니다.
4. Self-Descriptiveness
   • REST API 메세지 그 자체로 쉽게 이해할 수 있어야 합니다.
   • 즉, 별도의 주석이나 문서가 없어도 특정 REST API가 원하는 바를 쉽게 이해할 수 있어야 합니다.
5. Client-Server Architecture
   • REST API서버는 클라이언트에게 API를 제공하기만 합니다.
   • 서버는 클라이언트의 실행 문맥(Excution Context)을 알고 있을 필요가 없이 독립적인 REST API에 대한 서비스만 제공하면 됩니다. 따라서 클라이언트와 서버간의 역할 분담이 명확하게 분리 됩니다.
6. Layered System
   • REST API 서버는 Multi-layer로 구성 될 수 있습니다.
   • 클라이언트는 대상 서버에 직접 붙었는지 중간에 존재하는 서버와 통신하는지 알 수 없습니다. 이 중간에 존재하는 서버를 이용하여 Security관리, Encrypt, load balancing 등을 수행할 수 있어 확장성 확보 및 보안 향상이 가능합니다.
7. Code on demand (Optional)
   • REST API는 서버에서 수행 스크립트를 받아서 클라이언트 사이드 수행을 할 수도 있습니다.

---

REST의 장점

1. HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없습니다.
2. HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다.
3. HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.
4. Hypermedia API의 기본을 충실히 지키면서 범용성을 보장합니다.
5. REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
6. 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화합니다.
7. 서버와 클라이언트의 역할을 명확하게 분리합니다.
8. 원하는 데이터 표현을 사용할 수 있습니다.

Rest의 단점

• 표준이 존재하지 않아, 관리가 어렵습니다.

REST API는 API 설계 가이드일 뿐이지 명시적인 표준이 아닙니다. 따라서 관리가 어렵고, 좋은 API 디자인에 대한 가이드가 쉽지 않습니다. 어떤 가이드는 특정한 REST API에는 맞지만 또 다른 곳에는 맞지 않을 수 있습니다.

• 사용할 수 있는 메소드가 4가지 밖에 없습니다. (HTTP Method 형태가 제한적이다.), 즉, HTTP 메소드의 한계에 묶입니다.

REST API는 HTTP 메소드를 이용하여 URI에 대한 행위를 정의합니다. 따라서 간단한 수준의 메소드만 지원할 수 있습니다. 예를 들어 '메일을 보낸다.'라는 행위는 단일 메소드로 구현하기 쉽지 않은 일입니다.

• RDBMS와 어색한 관계

REST API를 RDBMS에 적극적으로 사용하기 위해서는 RESTful 한 테이블 구조가 필요하게 되는데, 이것보다는 NoSQL쪽이 더 잘 맞는 추세입니다.

• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재합니다.

PUT, DELETE를 사용하지 못하는 점
pushState를 지원하지 않는 점

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴집니다.

---

4.RESTful

4.1.RESTful이란

RESTful이란 REST의 설계 의도를 정확하게 지키는 시스템을 의미합니다.
RESTful 한 API는 구성요소들의 역할이 명확하게 분리되어 있어야 합니다. URI는 자원을 정확하고 인식하기 편하게 표현하는데에 집중하고, 자원에 대한 행위는 Uniform하게 HTTP 메소드를 통해 정의합니다.
나머지 Payload는 Json이나 XML,YAML과 같은 언어를 이용하여 별도로 정의합니다.

일반적으로 RESTful한 API를 설계하기 위해서 URI를 잘 정의하는 것이 중요합니다. URI의 설계 원리는 일반적으로 다음과 같습니다.

• 슬래시 '/' 는 계층 관계를 나타내는데 사용합니다.
• URI는 가독성이 중요합니다.
• 파일 확장자는 URI에 포함하지 않습니다.
• URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 합니다.
• 언더바 대신 하이폰을 사용합니다.
• 행위를 포함하지 않습니다.