Restful API

Rest API

API

데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하여, 서로 정보 교환을 가능 하도록 하는것

프로그램을 위한 인터페이스. 즉, 프로그램 간 커뮤니케이션을 담당하는 기능

 

 

Rest API에서 Rest 는 Representational State Transfer의 약자로 소프트웨어 프로그램 아키텍처의 한 형식이다.

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

Rest는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 할 수 있는 아키텍처 스타일이다.

Rest의 개념

웹에서 데이터를 전송하고 처리하는 방법을 정의한 인터페이스

HTTP URI를 통해 자원을 명시하고, HTTP method(get, post, put, delete)를 통해 해당 자원에 대한 CRUD를 적용하는 것을 의미한다.

Rest는 자원기반의 구조 설계의 중심에 resoure가 있고, method를 통해 resoure를 처리하도록 설계된 아키텍쳐를 의미한다.

웹의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

Rest API 등장 이유

서비스 / 어플리케이션의 개발로 멀티플랫폼, 멀티 디바이스의 시대가 열리고, 단순히 하나의 브라우저만 지원하던 이전과 달리 최근 서버 프로그램은 여러 웹 브라우저는 물론이며, 핸드폰의 어플리케이션과의 통신에 대응 할수 있어야 한다.

따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되어 Rest API가 등장 하였다.

 

클라이언트의 플랫폼이 PC의 브라우저에서 모바일, 어플리케이션 등으로 발전하여 서로 주고 받는 데이터들의 형식이 다른 만큼 그에 맞춰 서버또한 일일히 만드는 것을 비효율 적이므로 클라이언트 플랫폼을 전혀 고려하지 않고, 메세지 기반, XML, JSON 과 같은 클라이언트에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향 하게 되면서 RESTFUL한 API를 만들게 되었다.

 

 

Rest의 구성

1. 자원(Resource) - URL

2. 행위(Verb) - Http Method

3. 표현(Representations)

 

자원(Resource) - URL

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

자원을 구별하는 ID는 /posts/postId/1 같은 HTTP URI 이다

 

행위(Verb) - Http Method

HTTP 프로토콜의 Method를 사용한다.

GET, POST, PUT, DELETE 같은 메소드를 제공한다.

 

표현(Representations)

클라가 자원의 상태(정보)에 대한 조작을 요청하면, 서버는 이에 적정한 응답을 보낸다.

Rest에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.

현재는 대부분 JSON의 형태로 주고 받는다.

 

 

Rest의 특징

- 클라이언트 / 서버 구조

클라이언트 : 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관리하고 책임진다.

서버 : API를 제공하고, 비즈니스 로직 처리 및 저장을 책임진다.

각각의 역할이 확실하게 구분되고, 일괄적인 인터페이스로 분리되어 작동 할 수 있게 한다.

 

- 무상태성

rest는 HTTP의 특성을 이용하기 때문에 무상태성을 갖는다.

즉, 서버에서 어떤 작업을 하기 위해 상태정보를 기억할 필요가 없고, 들어온 요청에 대해 처리만 하기 때문에 구현이 쉽고 단순해진다.

 

- 캐시 처리 가능(Cachable)

HTTP의 기존 웹표준을 사용하기에 기본 웹에서 사용하는 인프라를 그대로 사용 가능하다.

대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.

캐시 사용을 통해 응답시간이 빨라지고, 서버의 트랜잭션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.

 

- 자체 표현 구조(Self-descriptivenss)

JSON을 이용하여 직관적으로 이해 할 수 있고, rest API 메세지 만으로 그 요청이 어떤 행위를 하는 지 알 수 있다.

 

- 계층화

클라와 서버가 분리 되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간매체를 사용 할수 있어 자유도가 높다.

 

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

HTTP 표준에만 따른다면 모든 플랫폼에서 사용이 가능하며, URI로 지정한 리소스에 대한 조작을 가능하게 하는 아키텍쳐 스타일을 말한다.

URI로 지정한 리소스에 대한 조작을 통일되고, 한정적인 인터페이스로 수행한다.

즉, 특정 언어나 기술에 종속되지 않는다.

 

 

Rest API의 중심 규칙
1. URI는 정보의 자원을 표현해야 한다.

2. 자원에 대한 행위는 Method로 표현한다.

 

 

 

RESTful API

RESTful

HTTP와  URI 기반으로 자원에 접근 할 수 있도록 제공하는 어플리케이션 개발 인터페이스 이다.

기본적으로 개발자는 HTTP 메소드와 URI만으로 인터넷에 자료를 CRUD 할 수 있다.

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

 

 

RESTful API 개발원칙

- 자원을 식별 할 수 있어야 한다.

URI만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다.

자원을 제어하기 위해서, 자원으 위치는 물론 자원의 종류까지 알수 있어야 한다.

서버가 제공하는 정보는 JSON, XML 형태로 HTTP body에 포함되어 전송 시킨다.

 

- 행위는 명시적이어야 한다.

Rest는 아키텍쳐, 방법론과 비슷하다. 따라서 정해진 방식을 꼭 사용하지 않는 것처럼 강제적이지 않다.

기존의 웹 서비스 처럼 get을 이용해서 update, delete를 해도 된다.

다만 Rest 아키텍쳐에는 부합하지 않으므로, Rest를 따른다고 할 수는 없다.

 

- 자기 서술적이어야 한다.

데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 어떤 어플리케이션을 실행해야 하는지를 알 수 있다.

즉, 데이터 처리를 위한 정보를 얻기 위해서 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다.

 

- HATEOS (Hypermedia as the Engine of Application State)

클라의 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함 할 수 있어야 한다.

Rest는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. -> 서버는 클라 응용 어플리케이션에 하이퍼 링크를 제공한다.

따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어 줄 것이 필요한다.

 

 

Rest의 단점

point-to-point 통신 모델을 기본으로 하기 때문에 서버와 클라가 연결을 맺고 상호작용 하는 어플리케이션 개발에는 적당하지 않다.

Rest는 URI, HTTP를 이용한 아키텍쳐링 방법에 대한 내용만 담고 있어, 보안과 통신규약 정책 같은 것은 개발자가 따로 진행 해야한다.

CRUD 메소드만 제공한다. 대부분의 일들을 처리가능하지만, 처리하기 모호한 표현도 있다.

 

 

 

URI와 URL의 차이점

결론 : URI는 URL의 의미를 품고 있다.

 

URI는 자원이 실제로 존재하는 위치를 가르키며, 자원에 대한 고유 식별자로서 URL의 의미를 포함한다.

 

자원을 식별하는 방법

Path Variable 방식과 Query Parameter 방식

 

Path Variable : 어떤 특정한 자원을 보여줄때 사용

/user/1
/user/2
/user/3

Query Parameter : 자원들을 필터링해서 보여줄 때 사용

/user?job=student
/user?job=student&age=10

 

예시)

http://jinshop.com/posts

jinshop.com에서 posts 라는 경로를 나타내고 있다.

서버에서는 해당 라우팅에 대한 알맞은 자원을 전송 해줄 것이며, 이는 자원의 실제 위치이므로 URL이다.

http://jinshop.com/posts/32

jinshop.com에서 32의 ID 값을 가지고 있는 자원을 식별하고 있다.

jinshop.com/posts/ 까지는 자원의 실제 위치 이기 때문에 URI임과 동기세 URL이며, 끝의 32는 식별자 이므로 URL을 포함하고 있는 URL이다.

 

 

 

URL과 URI의 차이점

 

RESTful API 이란