Computer A에서 Computer B로 100MB의 비디오를 전송하는 경우 Segment 과정이 없다면 사용자는 100MB의 비디오가 모두 로딩된 후 비디오를 볼 수 있다. Segment 과정이 있다면 Segment라는 작은 단위로 나뉘어 비디오 일부분을 미리 볼 수 있다.
연결이 중간에 끊기는 경우 Segmentation을 하지 않으면 큰 Data가 날아가 손실률이 크다.
<!-- 해당 Collection에 대한 전체 정보 -->
GET /cources
<!-- Document의 정보 조회 -->
GET /cources/front
4.2. Create(생성) - POST
<!-- backend coach 집합에 jjyoung라는 닉네임을 가진 코치 개체 생성 -->
POST /courses/back/coaches
<!-- body에 생성할 내용을 담음 -->
body {nickname: jjyoung}
4.3. Update(수정) - PUT
<!-- frontend coach 집합 중 첫 번째 코치 닉네임을 jjyoung로 수정 -->
PUT /courses/front/coaches
<!-- 수정할 내용을 body에 담음 -->
body {id: 1, nickname: jjyoung}
4.4. Delete(삭제) - DELETE
<!-- frontend crew 집합 중 jjyoung 삭제 -->
DELETE /courses/front/crews/jjyoung
5. REST Arichtecture의 제약 조건
5.1. Client - Server
: Client가 Server에게 Request를 보내고 Server가 Client에게 Response를 보내는 구조로 Server와 Client의 역할이 분리되어있다.
Server : API 제공과 제공된 API를 이용해 비즈니스 로직을 처리하거나 저장
Client : 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 관리
5.2. Stateless(무상태성)
: Client와 Server의 통신에는 상태가 없어야하며 모든 요청은 필요한 정보를 담고 있어야 한다.
☞ Client가 두 가지 요청을 보냈을 때 두 번째 요청 시 Server는 Client의 첫 번째 요청의 내용을 모르므로 두 번째 요청시에도 필요한 모든 정보를 담고 있어야 한다.
5.3. Cache
: 일반적인 서비스에서 60 ~ 80% 가량의 Transaction이 Select와 같은 조회성 트랜잭션이며 GET은 얼마든지 호출해도 매번 같은 결과를 만들어내므로(Idempotent) 캐싱이 가능하다.
5.4. Uniform Interface
5.4.1. Identification of Resources : 자원은 유일하게 식별 가능해야하며 Resource가 하나 이상의 유일한 특정 주소인 URI로 식별되어야 한다. ☞ 아직 POST Method로만 Request를 보내기 때문에 URI나 Request Body로 어떤 동작을 할 지 알려줘야 한다.
5.4.2. Manipulation of Resources through Representation : HTTP Method로 표현(CRUD)을 담아야 한다. ☞ 안전한 Operation과 안전하지 않은 Operation 간의 강한 분리를 제공해야 한다.
5.4.4. Hypermedia As the Engine Of Application State(HATEOAS)
: Hyperlink를 통해 Application의 상태가 전이되어야 한다.
☞ HTTP Response에 다음 Action이나 관계되는 Resource에 대한 HTTP Link를 함께 Return한다.
☞ 장점 : 요청 URI가 변경되더라도 Client는 Server에서 동적으로 생성된 URI를 사용함으로써 Client는 URI 수정에 따른 코드를 변경하지 않아도 된다.
5.5. Layered System
: 계층으로 구성이 가능해야 한다.
☞ Server는 다중 계층으로 구성될 수 있으나 Client 입장에서는 계층에 상관 없이 Server만 호출하면 된다.
e.g., 순수 비즈니스 로직을 수행하는 Server, 사용자 인증, 암호화(SSL), 로드 밸런싱 등을 하는 계층을 추가하거나 PROXY, 게이트웨이 같은 중간 매체 사용 가능
5.6. Code-On-Demand(Option)
: Server가 Network를 통해 Client에 Program을 전달하면 그 Program이 Client에서 실행될 수 있어야 한다.
e.g., JavaScript를 사용해 Server에서 Program 전달하면 Client에서 동적으로 실행 가능하다.
6. Richardson Maturity Model
Glory of REST
Level 3 : Hypermedia Controls
Level 2 : HTTP Verbs
Level 1 : Resources
Level 0 : The Swamp of POX
6.1. Level 0 : The Swamp of POX
: POX(Plain Old XML)를 주고받는 단순한 RPC Style System
☞ HTTP를 RPC 기반의 원격 통신을 위한 터널링 Mechanism으로 사용된다.
충족된 제약 조건 : Server-Client, Stateless, Layered System, Manipulation of Resources through Representation
RPC(Remote Procedure Call, 원격 프로시저 호출) : 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술 (= Client가 Server에 있는 Program을 실행하기 위해 사용하는 통신 기술) ☞ RPC를 이용하면 개발자는 실행 Program이 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.
☞ Client가 Server에게 Message를 보내 Program을 실행시키고 Server에서는 그 Program의 결과를 Client에게 전송
