REST

gga·2021년 6월 10일

API REST RESTful Architectur 레스트 레스트풀 아키텍쳐

web

목록 보기

4/6

대체 REST 란 무엇인가? 읽을 때마다 새롭고, 명확히 개념을 못 잡아서 이번에 정리를 해보려고 한다.

What is REST?

REST는 REpresentational State Transfer의 약자이다.
2000년도에 로이 필딩(Roy Fielding)의 박사 학위 논문에서 최초로 소개되었다. 발표 당시 웹이 HTTP의 우수성을 제대로 사용하지 못하고 있는 상황을 보고 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다.
분산 하이퍼 미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다.

만든 이유

정보를 구조적으로 저장하여 누구나 웹을 이용할 수 있도록
하루가 다르게 커져가는 웹의 규모에 대응하기 위해서
사회의 발전에 웹이 따라갈 수 있어야 한다.

단어 정리

리소스(Resource)

엔티티 집합의 개념적 매핑, 정보의 추상화, 무엇이든 리소스가 될 수 있다.
하나의 리소스는 여러 식별자를 가질 수있다.

식별자(Identifier)

리소스에 매핑된 일종의 이름(=URI)
하나의 식별자는 하나의 리소스에만 매핑될 수 있다.

표현(Representation)

클라이언트가 HTTP Method로 리소스를 조작하면 서버가 응답(JSON, XML 등)으로 보내주는 것을 의미하는데 이는 리소스가 아니라 리소스 표현이다.
표현에는 데이터와 메타데이터가 들어있다.

REST의 기본 원칙 6가지

REST 의 기본 조건을 만족하는 것을 RESTful 이라고 부른다.

1. Client-Server Model

서버와 클라이언트 역할이 분리된다. 인터페이스가 변경되지 않는 한 독립적으로 교체 및 개발 될 수 있다.
사용자 인터페이스와 데이터 처리 영역이 분리될 수 있어 유지 보수가 매우 쉬워진다.
데이터가 서버에 집중되므로 보안을 유지하기가 수월하다.

2. Stateless(무상태)

로이 필딩은 HTTP에서 영감을 받았기 때문에 REST 또한 stateless 제약을 반영한다. Connectionless로 인해 서버는 클라이언트를 식별할 수 없는 상태를 Stateless라고 한다.

Connectionless(비연결성)
클라이언트가 요청하고 서버가 해당 요청에 대한 응답을 하게되면 바로 연결을 끊는 것을 의미한다.

세션 정보를 서버에 저장하지 않고, 세션 상태(state)에 무관한 응답을 한다. 대표적으로 UDP와 HTTP가 있다.

stateful
서버와 클라이언트 간 세션 정보를 서버에 저장한다.
대표적으로 TCP 프로토콜이 있다.
Scaling이 자유롭다.
- Stateful : Scaled Out된 서버에 클라이언트 정보를 옮겨주는 등 부수적인 관리가 필요하다.
- Stateless : 서버는 클라이언트의 세션 관리를 하지 않으므로 신경쓸 필요가 없어진다.

3. Cache

캐시라는 제약 조건에 의해 서버가 응답 데이터마다 캐시 여부를 선언한다. 캐싱은 서버나 클라이언트 측에서 구현할 수 있다. 그로 인해 동일한 리소스에 대해 서버 요청 부하를 줄일 수 있다.

웹의 경우에는 개발자도구를 통해 확인 할 수 있다.

4. Layered System

클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요하다.
클라이언트 입장에서는 REST 서버만 호출한다. 하지만 서버는 API 서버(순수 비즈니스 로직)에 여러계층(사용자 인증, 암호화, 로드밸런싱 등)을 추가하여 유연한 구조로 만들 수 있고, 프록시, 게이트웨이와 같은 네트워크 기반의 중간매체를 사용할 수 있다.
인접한 외부 레이어를 제외한 모든 레이어로부터 내부 레이어를 숨겨 여러 레이어 간의 결합을 줄이고 진화성(evolvability)과 재사용성(reusability)을 증진시킨다.

1번부터 4번까지 제약 조건은 HTTP를 기반으로 하는 REST에서 어느정도 잘 지켜지고 있는 부분이라서 비교적 덜 주의를 기울여도 된다. Restful하기 위해서는 5번 Uniform Interface 조건을 잘 지켜야 한다.

5. Uniform Interface

표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요하다. 이는 기기나 애플리케이션 유형(웹 사이트, 모바일 앱)에 관계 없이 주어진 서버와 상호 작용하는 일관된 방식이 있어야 한다.
균일한 인터페이스를 얻으려면 다음과 같은 네가지 제약조건이 필요하다.

리소스는 URI로 식별된다.
Manipulation of Resources through Representation
- Represnetions을 통해서 리소스를 조작해야 한다.
- GET, DELETE 등 어떤 메소드를 쓰던간에 URI 경로는 동일해야 한다.
동작 HTTP Method URI
Create POST http://www.example/api/user/1
Read GET http://www.example/api/user/1
Update PUT http://www.example/api/user/1
Delete DELETE http://www.example/api/user/1
self-descriptive messages(자기 설명 메시지) : 지키기 어려움
메세지는 스스로를 설명해야한다. 메세지만 보고 무슨 뜻인지 알아야한다.

예시
```
GET /HTTP/1.1 200 OK
Host: www.example.com // 목적지 지정
Accept: application/json //body 표현 방법 지정
{"title": "rest", "text": "self-descriptive message"}
```

동작	HTTP Method	URI
Create	POST	`http://www.example/api/user/1`
Read	GET	`http://www.example/api/user/1`
Update	PUT	`http://www.example/api/user/1`
Delete	DELETE	`http://www.example/api/user/1`

HATEOAS(Hypermedia as the Engine of Application State) : 지키기 어려움
- 리소스 할당 후 클라이언트가 하이퍼링크를 통해 해당 URL에서 모든 리소스를 동적으로 검색할 수 있어야 한다.
- HTTP 헤더나 본문에 링크를 담아 만족 시킬 수 있다.
github api 를 통하여 이해해보자.
다음은 Chris Wanstrath의 GitHub 프로필을 가져오는 api이다.
https://api.github.com/users/defunkt

url이 붙은 키 값들이 하이퍼 링크이다.

6. Code-On-Demand(선택 사항)

실행 가능한 코드(예를 들면 자바스크립트)를 전송해 서버가 클라이언트의 기능을 확장할 수 있다.

REST 장단점

장점 - HTTP 사용

별도의 인프라 구축이 필요하지 않다
클라이언트와 서버의 분리
플랫폼 독립적
쉬운 사용

단점

표준이 존재하지 않다.
HTTP Method의 한계 : HTTP Method를 사용하기 때문에 CRUD 행위만 지원한다.

REST API(Application Programming Interfaces)

API 정의

응용프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

REST API란? REST 기반으로 서비스 API를 구현한 것이다.

SOAP
프로토콜, xml 형식만으로 데이터를 교환할 수 있다.
복잡한 구조로 무겁다.

다음 코드는 SOAP 메세지 예시이다.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:body pb="http://www.acme.com/phonebook">
  <pb:GetUserDetails>
   <pb:UserID>12345</pb:UserID>
  </pb:GetUserDetails>
 </soap:Body>
</soap:Envelope>
반면 REST API를 사용하면 다음과 같다
http://www.acme.com/phonebook/UserDetails/12345

구성

REST 방식은 URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근한다.

구성요소	내용	표현 방법
Resource	자원	HTTP URI
Verb	행위	HTTP Method
Representations(표현)	자원에 대한 행위의 내용	HTTP Message Pay Load

payload(페이로드)
전송되는 데이터를 뜻한다. 전송의 근복적인 목적이 되는 데이터의 일부분으로, 헤더와 메타데이터와 같은 데이터는 제외한다.
예를 들어 아래의 JSON에서 페이로드는 "Hello, world!"가 된다.
{
    "status":"OK",
    "data": {
        "message":"Hello, world!"
    }
}
참고
https://ko.wikipedia.org/wiki/%ED%8E%98%EC%9D%B4%EB%A1%9C%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)

디자인 가이드

URI는 정보의 자원을 표현해야 한다.
1) 리소스를 설명할 때 동사가 아닌 구체적인 명사 사용

2) spinal-case 사용

3) 파일 확장자는 URI에 포함시키지 않는다. http://restapi.example.com/members/soccer/345/photo.jpg (X)
Accept header를 사용하도록 한다.
```
GET /members/soccer/345/photo HTTP/1.1 
Host: restapi.example.com 
Accept: image/jpg
```
Accept로 원하는 형식을 보내면, 서버가 그에 맞춰 보내준다.
자원에 대한 행위는 HTTP 메소드로 표현한다.

HTTP 메소드

POST : 리소스를 생성한다.
PUT : 리소스를 수정한다.
DELETE : 리소스를 삭제한다.
GET : 리소스를 조회한다.

예시) 유저 4638 삭제
GET /user/delete/4638 -> DELETE /users/4638

HTTP 메소드는 리소스 행위에 맞게 작성한다.
create, delete, get, set 등 행위를 URL에 붙이지 않는다.
의미상 단수형 명사(user)보다는 복수형 명사(users)를 사용하는 것이 좋다.

참고

https://ijbgo.tistory.com/20
https://meetup.toast.com/posts/92
https://restfulapi.net/rest-architectural-constraints
https://5equal0.tistory.com/entry/StatefulStateless-Stateful-vs-Stateless-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%99%80-HTTP-%EB%B0%8F-REST
https://tibetsandfox.tistory.com/19

Roy Fielding의 REST 논문
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

gga

이전 포스트

URI와 URL

다음 포스트