REST API (2)

REST 

 

REST란? 추상적인 개념?

 

REST : REpresentational State Transfer

REST : a way of providing interoperability(상호운용성) between computer systems on the internet

 

WEB(1991) 등장 배경 : 어떻게 인터넷에서 정보를 공유할 것인가?

팀버너스리의 답 : 정보들을 하이퍼텍스트로 연결한다. 표현방식 : HTML 식별자 : URI 전송방법 : HTTP (프로토콜)

 

HTTP/1.0(1994-1996) Roy.T.Fielding : How do I improve HTTP without breaking the Web?

HTTP를 정의하게 된다면 기존에 구축되어진 웹과 호환성 문제가 생기는 것을 피하고 싶음 해결방법 : HTTP Object Model

HTTP Object Model -> 지금의 REST으로 발전되었다.

 

 

API

XML-RPC

XML-RPC : Microsoft가 원격으로 다른 시스템에 메소드를 호출할 수 있는 프로토콜을 만듦 XML-RPC -> SOAP 명칭 변경

 

REST 논문이 나온 후 SOAP과의 비교

SOAP -복잡하다 -규칙이 많다 -어렵다

REST -단순하다 -규칙이 적다 -쉽다

 

REST의 인기 상승, REST의 승리

2006년, AWS가 자사 API의 사용량의 85%가 REST임을 밝힘

2010년, Salesforce.com, REST API 추가

 

 

REST인가 아닌가?

REST의 정의가 기존 개발자들과 창시자인 로이 필딩의 정의가 다르다!

 

바인딩?

바인딩(Binding)이란 프로그램의 어떤 기본 단위가 가질 수 있는 구성요소의 구체적인 값, 성격을 확정하는 것을 말한다.

ex) int num = 123;

int는 자료형, num 변수이름, 123 자료값

이와 같이 각각의 구체적인 값을 할당하는 것을 바인딩이라고 한다.

 

버저닝?

API를 개발하면 시간에 따라 버전이 올라가는 것이 당연하다.

서버 운영을 하면서 서버의 API가 수정되거나 추가되는 것은 불가피하게 발생된다.

이렇듯 API가 변경될 때마다 오류들이 새로 나타날 수 있다.

그때마다 클라이언트의 버전을 업데이트하라고 강제성을 띄우기 보다는 API 버전 관리가 필요하다.

 

버저닝은 기존 API를 사용자에게 안정적으로 제공하면서,

새로운 버전의 API를 추가로 제공하여 사용자가 API의 버전을 선택 할 수 있도록하는 기술을 말한다.

 

 

CMIS (2008)

-CMS를 위한 표준

-EMC, IBM, Microsoft등이 함께 작업

-REST 바인딩 지원!!

REST 창시자 Roy.T.Fielding 왈 "NO REST in CMIS"

 

 

Microsoft REST API Guidelines (2016)

-uri는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다

-GET,PUT,DELETE,POST,HEAD, PATCH, OPTIONS을 지원해야 한다

-API 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킨다

 

사람들은 좋은 REST API에 부합한다고 생각함 BUT 로이 필딩은 REST API임을 반대

 

 

로이필딩의 REST API 설명

1. REST API는 hypertext-driven이어야 한다고 권고, REST API는 hypertext가 주도해야만 해
2. REST API를 위한 최고의 버저닝 전략은 버저닝을 안하는 것이다.

 

REST 아키텍쳐 스타일의 6가지 제약조건

REST 아키텍쳐란 웹에서 데이터를 주고받는 스타일을 의미합니다.

 

1) 클라이언트-서버(Client-Server)

리소스 : REST API가 리턴할 수 있는 모든 것. HTML, JSON, 이미지 등

 

리소스를 소비하려는 다수의 클라이언트가 네트워크를 통해 서버에 접근하는 구조로 웹 애플리케이션이 여기에 해당 됩니다. 사용자들에게 제공하는 interface인 User Interface와 데이터 스토리지, 알고리즘 등 서버 내부의 작업들을 분리함으로 써 UI는 여러 플랫폼에서의 이식성을 높이고, 서버는 그 구성요소를 단순화하여 확장 가능하도록 하였습니다. 클라이언트는 서버의 리소스 URI만 알고 있으면 되기 때문에 이 제약 조건에 의해 클라이언트와 서버가 서로 독립적으로 진화할 수 있게 되었습니다.

 

2) 상태가 없는 (Stateless)

클라이언트가 서버에 요청을 보낼 때 이전 요청의 영향을 받지 않음을 의미합니다. 서버는 클라이언트의 요청을 처리한 후 상태를 보관하지 않고, 요청 시마다 서로 다른 요청으로 인식되어 이전 작업 내용을 다음 요청 시 사용할 수 없습니다. ex) 로그인 후 그 다음 요청 시, 서버는 이전 요청에서 로그인한 사실을 모릅니다. 서버는 로그인 상태를 유지하지 못하므로 클라이언트는 요청을 보낼 때 마다 로그인 정보를 항상 함께 보내야 합니다. 서버가 리소스를 수정한 후 그 상태를 유지해야 하는 경우에는, 데이터베이스와 같은 퍼시스턴스에 상태를 저장해야 합니다. HTTP는 기본적으로 상태가 없는 프로토콜이고, 불특정 다수의 클라이언트가 요청하기 때문에 웹에서는 이전 요청 시의 상태를 유지 할 수 없습니다. 클라이언트에서 서버로의 각 요청에는 그 요청을 이해하는 데 필요한 모든 정보가 포함되어야 합니다. 서버에 저장된 환경 정보를 이용해서 이득 ex) 서버에서의 클라이언트 정보 유지 등을 취하면 안 됩니다. 따라서 세션의 정보는 전적으로 클라이언트가 가지고 있어야 합니다. 로그인했다는 세션 유지가 필요하다면 그 정보 또한 Client가 해당 정보를 가지고 서버에 전달해야 합니다. ex) JWT 사용

 

3) 캐시되는 (cacheable) 데이터

캐싱 : 주어진 리소스의 복사본을 저장하고 있다가 요청 시에 그것을 제공하는 기술

서버에서 리소스를 리턴할 때 캐시가 가능한지 아닌지 명시할 수 있어야 합니다. HTTP에서는 cache-control 이라는 헤더를 통해 리소스의 캐시 여부를 명시합니다.

1. 서버의 응답(복사본)을 cache에 보관하고
2. 동일한 요청 시 cache에 있던 응답(복사본)을 리턴합니다

요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능 한지 명시해야 합니다. 응답을 캐시 할 수 있다면 클라이언트에서 동일한 요청이 왔을 때 응답 데이터를 재사용할 수 있어야 합니다.

 

4) 일관적인 인터페이스 (Uniform Interface)

리소스에 대한 식별자, 리소스에 접근하는 방식, 요청 형식, 응답 형식 등이 애플리케이션 전반에 걸쳐 일반적이어야 합니다. 요청 또는 응답 메시지는 리소스를 변경, 삭제할 수 있는 충분한 정보를 가져야 합니다. ex) Todo 아이템의 경우 id를 클라이언트에 전달해야 Todo 아이템을 변경/삭제할 수 있습니다. 전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 약속된 Interface, 해당 규약을 REST하게 사용자들이 지킴으로써 추후에 사용하는 Client를 개발하는 사용자와 Server를 개발하는 사용자 간의 결합도가 낮아질 수 있습니다. Uniform interface 개발 REST 규약으로 4가지를 제시합니다.

• identification of resources
• manipulation of resources through representations
• self-descriptive messages
• hypermedia as the engine of application state.

5) 레이어드 시스템 (Layered System)

서버는 여러개의 레이어로 구성될 수 있으며 확장이 가능합니다. 인증 서버, 캐싱 서버, 로드 밸런서 등 여러 서버를 둘 수 있습니다. 클라이언트는 서버의 레이어 존재 유무를 알지 못합니다. 계층화된 시스템 아키텍처를 사용하여 각 구성들 간의 계층을 마음대로 상호작용 할 수 없도록 제한 함으로 써 Interface를 일원화할 수 있습니다.

 

6) 코드-온-디맨드 (Code-On-Demand)

서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 합니다. 이것은 사전 구현에 필요한 기능의 수를 줄임으로써 클라이언트를 단순화 시키는 것으로 우리가 평소 정적인 데이터를 xml 또는 json에 담아서 client로 보내고, client가 이것을 가공하는 것이 아닌 client에 보내는 데이터를 바로 실행 가능한 코드처럼 보내 이를 Client에서 실행하는 것을 말합니다.

 

REST API

REST API

REST API : REST 아키텍쳐 스타일을 따르는 API이다.

REST : 분산 하이퍼미디어 시스템을 (ex) 웹) 위한 아키텍쳐 스타일

아키텍쳐 스타일 : 제약조건의 집합

아키텍쳐 스타일, 즉 모든 제약조건을 지켜야 REST를 따른다고 할 수 있다.

 

REST를 구성하는 스타일

• client-server
• stateless
• cache
• uniform interface (지켜지기 어려운 제약 조건)
• layered system
• code-on-demand(optional)
• 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야함 javascript

HATEOAS 예시 나열……

 

HATEOAS / 독립적 진화 필수적

• 서버와 클라이언트가 각각 독립적으로 진화한다
• 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없다.
•  

REST가 잘 적용된 사례 : 웹

• 웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요는 없다
• 웹 브라우저를 업데이트 했다고 웹 페이지를 변경할 필요도 없다
• HTTP 명세가 변경되어도 웹은 잘 동작한다
• HTML 명세가 변경되어도 웹은 잘 동작한다
•  

웹의 상호운용성(interoperability)에 대한 집착

• Referer 오타지만 안 고침
• charset 잘못 지은 이름이지만 안 고침
• HTTP 상태 코드 416 포기함 (I’m a teapot, 만우절 장난)
• HTTP/0.9 아직도 지원함 (크롬에서 빼려고 시도 but 곳곳에서 프록시 오류 발생)

REST가 웹의 독립적 진화에 도움을 주었는가

• HTTP에 지속적으로 영향을 주었음
• HOST 헤더 추가
• 길이 제한을 다루는 방법이 명시 되었음 (414 URI Too Long)
• URI에서 리소스의 정의가 추상적으로 변경됨
• 기타 HTTP와 URI에 많은 영향을 줌
• HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
• Reminder:Roy T.Fielding이 HTTP와 URI 명세 저자 중 한명이다. > 지맘대로 만듦

 

REST는 성공했는가?

• REST는 웹의 독립적 진화를 위해 만들어졌다
• 웹은 독립적으로 진화하고 있다

결론 : REST는 성공하였다!!

 

REST API는 성공했는가?

• REST API는 REST 아키텍쳐 스타일을 따라야한다
• 오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다
•  

REST API도 제약조건들을 다 지켜야 하는가?

그렇다.

 

REST API란 하이퍼텍스트를 포함한 self-descriptive한 메시지의 unifrom interface를 통해

리소스에 접근하는 API이다.

REST API는 self-descriptive와 HATEOAS를 지켜야 한다.

 

REST API를 무조건 사용해야 하는가?

"시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면, REST에 대해 따지느라 시간 낭비하지 마라"

 

 

현재상태

 

그렇다면 현재 REST API는 구현되었을까요? 정답은 no입니다. 현존하는 모든 REST API는 REST API가 아니지만 REST API라고 불립니다. 하지만 우리는 끊임없이 노력하여 REST API를 구현하고 이를 REST API라고 부를 수 있어야합니다.

 

1. REST API 구현하고 REST API라고 부르기 (도전)
2. REST API 구현을 포기하고 HTTP API라고 부르기
3. REST API가 아니지만 REST API라고 부르기 (현재 상태)