REST API

API란?

Application Programming Interface 이다.

API란 정의된 프로토콜을 기반으로 상호 작용을 할 수 있도록 일종의 약속된 시스템이다.

즉, 라이브러리처럼 실제로 구현되어 사용할 수 있는 것이 아니라, 프로그램 구현에 있어 어떤 형태의 약속이라고 볼 수 있다.

 

그렇다면 RESTful API란

REST(Representation State Transfer) 이다.

네트워크 통신, 특히 웹(http)통신에 있어서 어떤 자원에 대한 CRUD(Create, Read, Update, Delete)요청을 상호 작용하기 위한 인터페이스이다.

Get,Post 등의 메서드를 사용하여 요청을 보내며 이런 REST를 준수하며 구현된 API를 RESTful API라고 한다.

RESTful API를 통해 요청이 수행될 때 Http URL을 통해 자원을 명시하고 Http 메서드(GET,POST,PUT,DELETE)를 통해서 해당 자원(URL)에 대한 CRUD동작을 적용한다. 

 

RESTful API의 구성

구성요소	내용	표현방법
Resource	자원	HTTP URI
Method(Verb)	자원에 대한 메서드	HTTP METHOD
Representation of Resource	자원에 대한 내용	JSON, Xml ...

RESTful API의 6가지 제한 조건

 1. Uniform Interface(일관된 인터페이스)

Uniform Interface란, Resource(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다. 이것은 요청을 하는 Client가 플랫폼(Android, Ios, Jsp 등) 에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 의미한다. 이러한 특징 덕분에 Rest API는 HTTP를 사용하는 모든 플랫폼에서 요청가능하며, Loosely Coupling(느슨한 결함) 형태를 갖게 되었다.

 

  2. Stateless(무상태성)

서버는 각각의 요청을 별개의 것으로 인식하고 처리해야하며, 이전 요청이 다음 요청에 연관되어서는 안된다. 그래서 Rest API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않는다. 이러한 무상태성때문에 Rest API는 서비스의 자유도가 높으며, 서버에서 불필요한 정보를 관리하지 않으므로 구현이 단순하다. 이러한 무상태성은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄이기 위함이다.

 

  3. Cacheable(캐시 가능)

RESTful API는 결국 HTTP라는 기존의 웹표준을 그대로 사용하기 때문에, 웹의 기존 인프라를 그대로 활용할 수 있다. 그러므로 RESTful API에서도 캐싱 기능을 적용할 수 있는데, HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 구현할 수 있고, 이것은 대량의 요청을 효울척으로 처리할 수 있게 도와준다.

 

  4. Client-Server Architecture (서버-클라이언트 구조)

RESTful API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 서버는 API를 제공하며, 클라이언트는 사용자 인증, Context(세션, 로그인 정보) 등을 직접 관리하는 등 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다.

 

  5. Self-Descriptiveness(자체 표현)

Rest API는 요청 메세지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다. 아래와 같은 JSON 형태의 Rest 메세지는 http://localhost:8080/board 로 게시글의 제목, 내용을 전달하고 있음을 손쉽게 이해할 수 있다. 또한 board라는 데이터를 추가(POST)하는 요청임을 파악할 수 있다.

 

HTTP POST , http://localhost:8080/board

{

"board":{

"title":"제목",

"content":"내용"

}

}

 

 

  6. Layered System(계층 구조)

RESTful API의 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조를 변경할 수 있다. 또한 Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있게 해준다. 하지만 클라이언트는 서버와 직접 통신하는지, 중간 서버와 통신하는지 알 수 없다.

정리

• 사용이 편리하다.
• 다양한 브라우저와 안드로이드, IOS의 등장으로 인해 어떤 플랫폼에서나 동작할 수 있다.
• RESTful API는 의도하는 바를 URL에 정확히 나타내므로 수신하는 입장에서도 유리하다.
• 이미 만들어진 HTTP 인프라를 그대로 사용한다.
• 각자의 역할이 명확히 분리되어 있다.

그러나

• 메서드가 제한적이라고 보는 견해도 있다.
• 정확한 표준이라고 할 것이 없다. 어떤 규정이라기보다 "약속"에 가깝다.

 

자주 사용되는 HTTP 상태 코드

상태코드	내용
200	클라이언트의 요청을 정상적으로 수행함
201	클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)
301	클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드 (응답 시 Location headder에 변경된 URI를 적어 줘야 합니다.)
400	클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드
401	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드 (로그인 하지 않은 유저가 로그인 했을 때, 요청 가능한 리소스를 요청했을 때)
403	유저 인증 상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드 (403 보다는 400이나 404를 사용할 것을 권고, 403자체가 리소스가 존재한다는 뜻이기 때문에)
404(Not Found, 찾을 수 없음)	서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
405	클라이 언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드
500	서버에 문제가 있을 경우 사용하는 응답코드

간단한 버전

• 1xx : 조건부 응답, 요청을 받았으며 작업을 계속함.
• 2xx : 성공, 요청을 성공적으로 처리했음.
• 3xx : 리다이렉션 완료, 리다이렉션으로 이동된 클라이언트 요청을 추가로 처리해 주어야한다.
• 4xx : 요청 오류, 클라이언트에 문제가 있음.
• 5xx : 서버 오류, 서버가 요청을 제대로 수행하지 못했음.