RESTFul Api 1장 REST 소개

REST 소개

이 글은 개인적으로 한빛소프트의 REST full api를 읽으면서 정리하는 글 입니다.

1.1 Hello World Wild Web

1990 년도에 팀 버너스리는 ( World Wide Web ) 프로젝트를 시작했고 

1년간 작업한 후 다음과 같은 내용을 구현 했다.

URI : 모든 웹 도큐먼트에 할당된 유일한 주소 ( Uniform Resource Indentifier ) 흔히 index page main page

HTTP : 인터넷을 통해 컴퓨터가 통신하기 위한 메세지 기반의 언어 ( Hyper Text Transfer Rrotocol )

HTML : 정보를 제공하는 도큐먼트를 표현하기 위한 하이퍼텍스트 마크업 언어

Nexus : 월드와이드앱 이라고 불렀으나 이후에 혼동을 피하기 위해 최초의 서버를 Nexus 라고 지음 롤로 치면 핵심이 넥서스..

웹은 초반 성장세에 비해 트래픽이 많이 몰려서 문제점이 많았다. 

그래서 필딩이란 사람이 웹 구현 방법을 개선하기 시작했다. 

필딩은 제약점들을 여섯가지 범주로 묶어 웹의 구조적 스타일 ( Web's architecural style ) 을 만들었다.

그렇다면 웹의 구조적 스타일이란 무엇인가?

웹 구조적 스타일 6가지 

1. 클라이언트 / 서버

핵심은 관심사의 분리다. 즉 시스템에서 클라이언트와 서버의 역활은 분명하게 나뉜다. 웹의 일관 된 인터페이스를 따른다는 전제하에, 클라이언트와 서버는 각자의 언어 및 기술을 사용하여 독립적으로 구현되고 배포될 수 있다.

2. 균일한 인터페이스 

웹을 구성하는 클라이언트, 서버, 네트워크 드으이 매체 간 인터페이스는 각 인터페이스의 일관성에 기반한다. 이러한 웹 컴포넌트들 중 하나라도 기존에 구축된 표준에 벗어나면, 웹 커뮤니케아션 체계는 붕괴된다. 

웹 컴포넌트들은 네가지 인터페이스 제약조건에 따라 운영됨

1. 리소스 식별

고유 식별 URI

2. 표현을 통한 리로스 처리

리소스는 ( 예를 들어 api 에서 콜했을 때 리턴으로 받는 json ) 상호작용하는 방법에 차이가 있을 뿐이다. 즉 서비스를 이용하는 html 에 따라 다르게 표현 될 수 있지만 리소스는 동일하다.

3. 자기 서술적 메시지

리소스의 요청 상태는 클라이언트의 요청 메세지로 표현된다. 리소스의 현재 상태는 그 요청에 응답하는 서버의 응답 메시지로 표현되어, 클라이언트에 전달된다. 

클라이언트의 요청을 받아들일 것인가 여부는 전적으로 서버에 달려 있다.

HTTP 메시지는 일정한 형태로 여러 종류의 메타데이터 정보를 넣을 수 있는 헤더를 제공한다.

4. 애플리케이션 상태 엔진으로서의 하이퍼미디어

? 의미를 잘 모르겠음..

3. 계층 시스템

계층시스템은 흔히 마이크로 서비스의 게이트웨이 or 프록시 서버를 지칭한다. 

웹의 일관된 인터페이스를 사용하면 중간매체를 클라이언트와 서버 사이에 마치 없는 것처럼 배치할 수 있다.

일반적으로 네트워크 기반의 중간매체는 특별한 목적을 위해 클라이언트와 서버간 통시늘 가로챌 수 있다. 주로 보안을 강화하거나 캐싱 또는 로드밸런싱 오토스케일링 등의 용도로 사용된다. 

4. 캐시

캐시는 웹 구조의 중요 제약조건 중 하나다. 캐시라는 제약조건에 의해 웹 서버가 응답 데이터마다 캐시 여부를 선언한다.

 

5. 상태없음 ( stateless )

상태 없음은 웹 서버가 클라이언트의 상태를 관리할 필요가 없다는 의미다. 따라서 각 클라이언트는 웹 서버와 상호작용하는 관련 상황 정보를 직접 관리해야 한다. 

클라이언트는 웹 서버와 상호작용하는 관련 상황 정보를 직접 관리해야 한다.

웹 서버는 웹 애플리케이션과의 복잡한 커뮤니케이션을 위해 필요한 상태 관리를 클라이언트에 맡김으로 더 많은 클라이언트에 서비스할 수 있다.

6. 주문형 코드

Code-On-Demand를 많이 사용한다. 이 제약조건은 스크립트나 플러그인 같은 실행 가능한 프로그램을 일시적으로 클라이언트에 전송하여, 클라이언트가 실행할 수 있도록 한다. 자바스크립트, 플래시 같은 웹 브라우저 기반의 기술들이 있다.

웹 표준

필딩은 팀 버너스리를 비롯한 다른 개발자들과 함께 웹 확장성을 높이는 작업을 했다. 이런 작업을 통해 표준 설계안을 만들었다.

HTTP/1.1 스펙을 작정하였다. 또한, URI 문법 형식도 RFC 3986 으로 규정하였다. 이렇게 정리된 표준은 웹을 통해 급속히 확산 되었고 웹이 지속적으로 성장하는 기틀을 마련했다.

REST

2000년 웹의 확장과 관련된 위기를 극복한 후, 필딩은 자신의 박사학위 논문에서 '웹의 구조적 스타일' 이라고 이름 붙인 이름 붙인 이 문제에 대해 설명하였다. 필딩이 

Representational State Transfer 표현상태전이 REST 이름을 붙인 웹의 구조적 스타일에 대한 설명은 제약조건들로 이루어져 았다.

REST API

REST 구조 스타일은 최근 웹 서비스를 위한 API 설계에 많이 적용되고 있다. REST구조 스타일에 적합한 Web API를 REST API 라고 한다.

REST API를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다. 

REST API는 상호 연결된 리소스의 결합체며, 이 리소스 집합을 일컬어 REST API의 리소스 모델이라고 한다. 

REST API 설계

RESTful 한 api 를 설계하면서 다음과 같은 질문에 답을 할 줄알아야 한다.

• URI 경로 세그먼트는 언제 복수로 써야 하는가?
• 리소스의 상태를 업데이트 하려면, 어떤 메서드를 사용해야 하는가
• CRUD가 아닌 연산을 어떻게 URL에 매핑하는가
• 특정한 시나리오에 가장 적합한 HTTP 응답은 무엇인가
• 리소스 상태 표현의 버전은 어떻게 관리할 수 있는가
• JSON에 포함된 하이퍼링크는 어떻게 구조화하는가