[CS Web] REST

REST API

다양한 테스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신하기 위해 등장했다.

 

여기서 REST란, Representational State Transfer의 약자로, 자원을 이름으로 구분해 해당 자원의 상태를 주고받는 모든 것을 말하며, API는 Application Programming Interface의 약자로, 컴퓨터의 기능을 실행시키거나 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법을 말한다. => 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스이다.

 

따라서, REST API는 REST를 기반으로 만들어진 API로, 클라이언트와 서버간의 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스인 것이다. REST API는 내 컴퓨터가 아닌 다른 컴퓨터에서 실행시키는 api를 보다 효율적으로 사용하기 위해 고안된 개념으로, http 통신을 통해 자원을 보다 효율적으로 관리하기 위해 사용한다.

 

데이터 요청이 REST API로 전송되면 일반적으로 하이퍼텍스트 전송 프로토콜(일반적으로 HTTP)을 통해 수행된다. 요청이 수신되면 RESTful API (REST용으로 설계된 API) 는 HTML, XML, 일반 텍스트, JSON 등 다양한 형식으로 메시지를 반환할 수 있다. JSON은 모든 프로그래밍 언어에서 읽을 수 있고 가볍기 때문에 메시지 형식으로 선호된다.

 

 

REST 구성 요소

1. 자원 (Resource) - HTTP URI

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
• 자원을 구별하는 ID는 '/groups:/group_id' 같은 HTTP URI
• 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 서버에 요청한다.

2. 행위 (Verb) - HTTP Method (GET, POST, PUT, DELETE)

3. 내용 (Representations) - HTTP Message Pay Load

• 클라이언트가 자원의 상태(정보)에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다. REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 응답을 받을 수 있다.
• JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적이다.

 

 

REST의 특징

1. Server-Cliient (서버-클라이언트 구조)

• REST 아키텍처는 클라이언트, 서버, 리소스로 구성되며 HTTP를 통해 요청을 처리한다.

2. Stateless (무상태)

• 클라이언트 콘텐츠가 서버에 저장되지 않는 대신 세션 상태에 대한 정보는 클라이언트에 보관된다.

3. Cacheable (캐시 처리 가능)

• 캐싱을 사용하면 일부 클라이언트-서버 상호 작용이 필요하지 않다.

4. Layered System (계층화)

• 클라이언트-서버 상호 작용은 추가 계층을 통해 조정될 수 있다. 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있다.

 

5. Uniform Interface (인터페이스 일관성)

RESTful API 설계의 핵심이며, 다음 4가지를 포함한다.

• 요청 리소스 식별
  • 리소스는 요청에서 식별되며 클라이언트에 반환된 표현과 별개이다.
• 표현을 통한 리소스 조작
  • 클라이언트는 리소스를 나타내는 파일을 받는다. 이러한 표현에는 수정 또는 삭제가 가능하도록 충분한 정보가 있어야 한다.
• 자체 설명 메시지
  • 클라이언트에 반환된 각 메시지에는 클라이언트 정보를 처리하는 방법을 설명하는 데 충분한 정보가 포함되어 있다.
• 애플리케이션 상태 엔진으로서의 하이퍼미디어
  • 리소스에 액세스한 후 REST 클라이언트는 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 검색할 수 있어야 한다.

 

최근에는 OpenAPI 사양이 REST API 정의를 위한 공통 표준으로 등장했다. OpenAPI는 개발자가 REST API 인터페이스를 구축해 사용자가 최소한의 추측으로 이해할 수 있도록 언어에 구애받지 않는 방식을 설정한다.

 

또 다른 API 표준은 REST의 대안인 쿼리 언어이자 서버 측 런타임인 GraphQL이다. GraphQL은 클라이언트가 요청한 데이터만 정확하게 제공하는 것을 우선시한다. REST 대신 GraphQL을 사용하면 개발자는 단일 API 호출로 여러 데이터 소스에서 데이터를 가져오는 요청을 구성할 수 있다.

 

 

REST의 장단점

장점

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

단점

• 표준자체가 존재하지 않아 정의가 필요함
• HTTP Method 형태가 제한적
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL 보다 Header 정보의 값을 처리해야 하므로 전문성이 요구됨
• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음 (익스플로러)

 

 

 

채용공고 보면 자격요건에 RESTful API가 항상 적혀있던데,
RESTful API가 대체 뭐지 ?

 

REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다고 말할 수 있다.

 

REST API 설계 규칙

1. URI는 동사보다는 명사를, 대문자보다는 소문자를 사용해야 함

http://ssafy.com/Running 

http://ssafy.com/run

 

2. 마지막에 슬래시 (/)를 포함하지 않는다

http://ssafy.com/ 

http://ssafy.com

 

3. 언더바 대신 하이픈

http://ssafy.com/hyunseok_hyunjin

http://ssafy.com/hyunseok-hyunjin

 

4. 파일확장자는 URI에 포함하지 않는다

http://ssafy.com/velkoz.jpg 

http://ssafy.com/velkoz

 

5. 행위를 포함하지 않는다

http://ssafy.com/delete-post/1 

http://ssafy.com/post/1

 

 

RESTful의 목적 : 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

RESTful한 API를 구현하는 근본적인 목적이 성능 향상이 아니라 '일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것'이 주 동기이니, 성능이 중요한 상황에서는 굳이 RESTful한 API를 구현할 필요는 없다.

 

 

요청 방식

Path Variable

전체 데이터 또는 특정 하나의 데이터를 다룰 때처럼 리소스를 식별하기 위해 사용

GET
/users/10

 

Query Parameter

데이터의 좀 더 깊은 속성 값을 조정하거나, 세밀하게 데이터를 정렬하거나 필터링 하고 싶을 경우 적합하다.

GET
/users?user_id=10

 

 

 

SOAP

SOAP는 다양한 언어와 플랫폼에서 구축된 애플리케이션이 통신할 수 있도록 처음 설계된 표준 프로토콜이다. SOAP로 설계된 API는 메시지 형식으로 XML을 사용하고 HTTP 또는 SMTP를 통해 요청을 받는다. 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 긱본 제공 규칙을 적용하므로 페이지 로드 시간이 길어질 수 있다.

 

REST와 SOAP는 온라인 데이터 전송에 대한 두 가지 서로 다른 접근 방식이며, 두 가지 모두 웹 애플리케이션 간에 데이터를 통신할 수 있는 애플리케이션 프로그래밍 인터페이스(API)를 구축하는 방법을 정의한다. 근본적으로 SOAP는 W3C에서 유지관리하는 공식 프로토콜인 반면, REST는 아키텍처 스타일이다. 즉, 프로토콜이냐 아니냐라는 차이가 있다. 그리고 이는 RESTful 웹 API에 대한 공식 표준이 없음을 의미한다.

 

많은 레거시 시스템은 여전히 SOAP를 준수할 수 있지만 REST는 나중에 출시되었으며 웹 기반 시나리오에서 더 빠른 대안으로 간주되는 경우가 많다. REST는 유연한 구현을 제공하는 일련의 지침인 반면, SOAP는 XML 메시징과 같은 특정 요구 사항이 있는 프로토콜이다.

 

REST API는 가벼우므로 IoT, 모바일 애플리케이션 개발, 서버리스 컴퓨팅 같은 새로운 컨텍스트에 이상적이다. SOAP 웹 서비스는 기업의 다양한 요구 사항에 부합하는 기본 보안 및 트랜잭션 규정 준수를 제공하지만 이로 인해 요구사항이 더 무거워지기도 한다. 또한 Google Maps API와 같은 많은 공개 API는 REST 지침을 따르고 있다.

 

 

* 서버리스 : 개발자가 서버를 관리할 필요 없이 애플리케이션을 구축하고 실행할 수 있는 클라우드 네이티브 개발 모델을 말한다. 서버리스에도 서버가 있긴 하지만 앱 개발에서 추상화된다. 클라우드 공급자가 클라우드 인프라와 앱 확장을 모두 관리한다는 점에서 다른 클라우드 컴퓨팅 모델과 다르다. 서버리스 앱은 호출 시 요청 시 자동으로 실행되는 컨테이너에 배포된다. 즉시 시작할 수 있는 비동기식, 상태 비저장 앱에 이상적이다. 즉, 수요가 드물고 예측할 수 없이 급증하는 사용 사례에 적합하다. 수신 이미지 파일의 일괄 처리, 디비에 들어오는 변경 사항을 관찰 후 품질 표준에 따라 변경 사항 확인하기, 자동으로 변역하기, 수신 데이터 스트림, 채팅 봇, 예약작업 등이 있다.

쿠버네티스 자체로는 서버리스 앱을 실행할 수 없지만 Knative를 사용하면 된다. Knative는 쿠버네티스에서 서버리스 앱을 배포, 실행 및 관리하기 위한 구성 요소를 추가하는 오픈 소스 커뮤니티 프로젝트이다.

 

 

GraphQL

애플리케이션 프로그래밍 인터페이스(API)를 위한 쿼리 언어이자 서버측 런타임으로 클라이언트에게 요청한 만큼의 데이터를 제공하는 데 우선 순위를 둔다. API를 더욱 빠르고 유연하며 개발자 친화적으로 만들기 위해 설계되었다. Facebook에서 개발했다.

 

GraphQL 이란 ?

 

REST와 차이점

• GraphQL은 보통 하나의 엔드포인트를 가진다.
• GraphQL은 요청할 때 사용하는 쿼리에 따라 다른 응답을 받을 수 있다.
• GraphQL은 원하는 데이터만 받을 수 있다.

 

 

REST 세 줄 요약

• HTTP URI를 통해 자원(Resource)을 명시
• HTTP Method(POST, GET, PUT, DELETE, PATCH 등)을 통해
• 해당 자원(URI)에 대한 CRUD Operation을 적용

=> HTTP URI를 통해 Client와 Server의 통신하는 방식 중 하나로, HTTP Method를 통해 자원을 처리(CRUD)하도록 설계된 아키텍처를 말한다.

 

 

REFERENCE

[네트워크] REST API란? REST, RESTful이란?

What is an API?

REST API란 무엇인가?

GraphQL(그래프 QL)란? 개념과 필수 용어 알아보기

[간단정리] GraphQL이란? (REST api와 차이점)