카라멜마끼아또

개인 공부를 위한 공간입니다
상업적 용도로 활용되지 않습니다

REST?

Representational State Transfer

자원의 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

프로토콜이나 표준이 아닌 아키텍쳐 제약 조건

SW의 아키텍쳐를 어떻게 형성할 지에 대한 가이드라인

API?

Application Programming Interface

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

프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있음

REST API, RESTful API

Web에서 활용하게 되는 API가 REST가이드라인을 따른다면 RESTful API

6개의 가이드라인을 전부 따르지 않아도 어느정도 REST 제약을 지킨다면 REST API

REST API?

REST 기반으로 서비스 API를 구현한 것

• 사내 시스템을 REST기반으로 분산해 확장성, 재사용성을 높여 유지보수, 운영 편리성을 높일 수 있음
• HTTP표준 기반으로 구현하기 때문에 HTTP를 지원하는 언어로 클라이언트, 서버 구현 가능
• 즉, REST API제작하면 Delphi, Java, C# 등을 이용해 클라이언트를 제작 할 수도 있음

REST 가이드라인

1. Uniform Interface

URL만 보고 어떤 정보가 들어올지 예측 가능하도록 하나의 URL로는 한 개의 데이터만 가져와야 함

ex) instagram.com/username/photos

 >> 특정 회원의 인스타그램 사진첩임을 유추 가능

전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 약속된 Interface

클라이언트 개발자와 서버 개발자 사이의 결합도를 낮춤

Uniform Interface 제약 조건

•  Identification of resources

리소스가 URI로 식별

• Manimpulation of resources through representations

Represestation 전송을 통해 리소스를 조작 가능

>> 리소스 CRUD 할 때에도 메소드를 저장하는 것을 의미

• Self-Descriptive messages

자기서술적 메시지

메시지만으로 어떤 메시지인지 알 수있어야 함

self-descriptive message의 예시

Request

Get / HTTP/1.1
Host: www.example.org

Response

HTTP/1.1 200 OK
Content-Type: application/json-patch+json
\[{ “op” : “remove”, “path” : “a/b/c"}\]

• Hypermedia as engine of application state (HATEOAS)

Hypermedia로 어플리케이션 상태 설명

HTTP/1.1 200 OK
Content-Type: application/json
Link: </articles/1>; rel=“previous”,
      </articles/3>; rel=“next”;
{
    “Title” : “The second article”,
    “content” : “Hello! Brother"
}

이렇게 표현해도 되고

HTTP/1.1 200 OK
Content-Type: application/json
{
    “Title” : “The second article”,
    “content” : “Hello! Brother"
    href :
    {
        previous : /article/1
        next : article/3
    }
}

Json에 포함시켜도 됨

2. Client-Server 역할 구분

클라이언트 : Request

서버 : Response

사용자들에게 제공하는 Interface인 User Interface와 Data Storage, 알고리즘 등 서버 내부의 작업을 분리

>> User Interface는 여러 플랫폼에서 이식성 향상을 기대

>> 서버 구성요소 단순화하여 확장성 기대

클라이언트는 서버의 리소스 URI만 알면 되기 때문에 클라이언트와 서버가 서로 의존하지 않고 별도로 진화 가능

3. Stateless

각 요청은 독립적으로 처리

요청들 사이에 의존성이 존재 X

클라이언트에서 서버로의 Request에는 그 요청을 이해하기 위한 정보가 포함되어야 함

세션의 정보는 전적으로 클라이언트가 보유

Ex)

로그인 세션 유지가 필요하다면 그 정보 또한 클라이언트가 가지고 서버에 전달

대표적으로 JWT토큰 등을 사용

4. Cacheable

요청에 대한 응답 내의 데이터에 캐시 가능 여부를 명시해야 함

응답을 캐시할 수 있다면 동일한 Request시에 응답 데이터 재사용 가능해야 함

Cache-Control 헤더를 통해 캐시 여부 명시

5. Layered System

요청 처리, DB 저장 등 여러 단계를 거쳐 요청을 처리

계층화된 시스템 아키텍처를 사용하여 각 구성원들 사이의 계층간 상호작용 제한

>> Interface 일원화

6. Code on demand(Optional)

서버가 네트워크를 통해 클라이언트에 전달한 Javascript 등과 같은 프로그램들은 그 자체로 실행이 가능해야 함

>> 사전 구현에 필요한 기능을 간소화하여 클라이언트 단순화

바로 실행 가능한 코드를 클라이언트에 보내서 실행

REST 구성요소

1. Resource

자원(URI)

모든 자원에 고유한 ID존재, 이 자원은 서버에 존재

자원을 구별하는 ID는 HTTP URI (/groups/:group_id)

클라이언트는 URI를 통해 자원을 지정, 해당 자원의 상태(정보)에 대한 조작을 서버에 요청

2. Verb

행위

HTTP 메소드

HTTP프로토콜 메소드 사용

HTTP프로토콜은 GET, POST, PUT, DELETE등의 메소드 제공

3. Representation of Resource

표현

클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버는 이에 적절한 응답 전송

REST에서 하나의 자원은 JSON, XML, TEXT, RSS등 여러 형태 가능

보통 Json, XML 사용