IT 용어_REST API

REST API 개념

    REST API(RESTful API라고도 함, Representational State Transfer API)는 REST 아키텍처 스타일의 제약 조건을 준수하고 RESTful 웹 서비스와의 상호 작용을 허용하는 애플리케이션 프로그래밍 인터페이스다. 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용한다. 2000년도에 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다. REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

    REST는 프로토콜이나 표준이 아닌 일련의 아키텍처 제약 조건이다. API 개발자는 다양한 방법으로 REST를 구현할 수 있다. 클라이언트 요청이 RESTful API를 통해 이루어지면 리소스 상태 표현을 요청자 또는 endpoint로 전송한다. 이 정보 또는 표현은 HTTP를 통해 JSON(Javascript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트와 같은 여러 형식 중 하나로 전달한다. JSON은 그 이름에도 불구하고 언어에 구애받지 않고 인간과 기계 모두가 읽을 수 있기 때문에 가장 일반적으로 사용되는 파일 형식이다.

    예전에는 API 요청을 보내거나 받을 때 XML이나 HTML을 사용했었지만, 최근에는 JSON을 사용하는 것이 추세이다. XML은 사용할 때 데이터를 인코딩/디코딩하는 게 번거로울 때가 많아 여러 프레임워크에서 지원하지 않는 경우가 많다. JavaScript는 API를 받아올 때 JSON을 사용하도록 만들어져 있기 때문에 JSON으로 파싱 하는 내장 메서드를 가지고 있다. Python도 JSON으로 파싱 하거나 데이터를 다룰 수 있는 메서드들을 지원한다(json.loads() or json.jumps())

 

REST API 구성

 - 자원(RESOURCE) : URI

 - 행위(Verb) : HTTP METHOD

 - 표현(Representations)

 

REST API 장점

 ○ 확장성

  - REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거한다. 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거한다. 이러한 모든 기능은 성능을 저하시키는 통신 ㅣ병목 현상을 일으키지 않으면서 확장성을 지원한다.

 ○ 유연성

  - RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않는다. 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상한다. 예를 들어, 개발자는 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다. 

 ○ 독립성

  - REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.

 

REST의 특징

 ○ Uniform(유니폼 인터페이스)

  - Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.

 ○ Stateless(무상태성)

  - REST는 무상태성 성격을 갖는다. 다시 말해 작업을 위한 상태 정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

 ○ Cacheable(캐시 가능)

  - REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

 ○ Self-descriptiveness(자체 표현 구조)

  - REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다.

 ○ Client - Server 구조

  - 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 된다. REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어든다.

 ○ 계층형 구조

  - REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.

 

REST API 디자인 가이드

 - REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있다.

1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

 

REST API 준수사항

API가 RESTful로 간주되려면 다음 기준을 준수해야 한다.

 - HTTP를 통해 요청을 관리하는 클라이언트, 서버 및 리소스로 구성된 클라이언트-서버 아키텍처

 - 상태 비저장 클라이언트-서버 통신, 즉 get 요청 간에 클라이언트 정보가 저장되지 않고 각 요청이 분리 및 연결되지 않음

 - 클라이언트-서버 상호 작용을 간소화하는 캐시 가능한 데이터

 - 각 유형의 서버(보안, 로드 밸런싱 등을 담당하는 서버)를 구성하는 계층화된 시스템은 요청된 정보를 클라이언트에 보이지 않는 계층으로 검색하는 작업을 포함

 - Code on demand : 요청 시 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장하는 기능

 - 정보가 표준 형식으로 전송되도록 하는 구성 요소 간의 균일한 인터페이스

  1. 요청된 리소스는 식별 가능하며 클라이언트에 전송된 표현과 별개

  2. 표현에는 그렇게 할 수 있는 충분한 정보가 포함되어 있기 때문에 수신한 표현을 통해 클라이언트가 리소스 조작 가능

  3. 클라이언트로 반환되는 자체 설명 메시지에는 클라이언트가 이를 처리하는 방법을 설명하기에 충분한 정보가 있다.

  4. 하이퍼텍스트/하이퍼미디어 사용 가능. 즉, 클라이언트는 리소스에 액세스 한 후 하이퍼링크를 사용하여 현재 수행할 수 있는 다른 모든 작업을 찾을 수 있어야 함.

 

REST API 작동방식

 - REST API의 기본 기능은 인터넷 브라우징과 동일하다. 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속한다. API 개발자는 서버 애플리케이션과 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명한다. 다음은 모든 REST API 호출에 대한 일반 단계이다.

1. 클라이언트가 서버에 요청을 전송. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정.

2. 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인.

3. 서버가 요청을 수신하고 내부적으로 처리.

4. 서버가 클라이언트에 응답을 반환. 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다. 응답에는 클라이언트가 요청한 모든 정보도 포함된다.

 

REST API 클라이언트 요청 구성요소

 ○ 고유 리소스 식별자

  - 서버는 고유한 리소스 식별자로 각 리소스를 식별한다. REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행한다. 

 ○ 메서드

  - 개발자는 종종 HTTP를 사용하여 REST API를 구현한다. HTTP 메서드는 리소스에 수행해야 하는 작업을 서버에 알려준다. 다음은 4가지의 일반적인 HTTP 메서드이다.

 ○ GET

  - 클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스 한다. GET 요청을 캐싱하고 REST API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시한다.

 ○ POST

  - 클라이언트는 POST를 사용하여 서버에 데이터를 전송한다. 여기에는 요청과 함께 데이터 표현이 포함된다. 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있다.

 ○ PUT

  - 클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다. POST와 달리 REST 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일하다.

 ○ DELETE

  - 클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다. DELETE 요청은 서버 상태를 변경할 수 있다. 하지만 사용자에게 적절한 인증이 없으면 요청은 실패한다.

 

REST API 서버 응답에 포함된 것

 ○ 상태표시줄

  - 요청 성공 또는 실패를 알리는 2XX, 4XX, 5XX 등의 상태 코드를 표시한다.

 ○ 메시지 본문

  - 응답 본문에는 리소스 표현이 포함된다. 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택한다. 클라이언트는 데이터 작성 방식을 일반 텍스트로 정의하는 XML 또는 JSON 형식으로 정보를 요청한다. 예를 들어, 클라이언트가 John이라는 사람의 이름과 나이를 요청하면 서버는 다음과 같이 JSON 표현을 반환한다. '{"name":"John", "age":30}'

 ○ 헤더

  - 응답에는 응답에 대한 헤더 또는 메타데이터도 포함된다. 이는 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함한다.

 

 

출처 : https://www.redhat.com/en/topics/api/what-is-a-rest-api

What is a REST API?

출처 : https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

출처 : https://aws.amazon.com/ko/what-is/restful-api/

RESTful API란 무엇인가? - RESTful API 초보자 가이드 - AWS

출처 : https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog