REST API란 무엇일까?

REST(Representational State Transfer)를 설명하기 전에 Open API에 대해 설명하려고 한다.

Open API(Application Programming Interface) Open API는 말 그대로 개방형 API를 말한다. 예를들어 Naver,  통계청, 기상청과 같은 관공서에서 가지고 있는 데이터를 외부 응용 프로그램에서 사용할 수 있도록 Open API를 제공하고 있다. Open API와 함께 자주 거론되는 기술이 REST이며, 대부분 Open API는 REST 방식으로 지원되고 있다.

Open API의 대부분이 REST API라는 것을 알 수 있는데 그럼 Representational State Transfer 은 무슨 뜻일까 ? 대표적인 상태 전송..? 뭔가 모호하다.

REST는 웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용하는 것으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법을 의미한다.

REST API는 HTTP URI + HTTP Method 두 가지를 이용하여 HTTP URI를 통해 제어할 자원(Resource)을 명시하고, HTTP Method(GET, POST, PUT, DELETE)을 통해 해당 자원(Resource)을 제어하는 명령을 내리는 방식이다.

Http 프로토콜에 정의된 4개의 메서드들이 자원에 대한 CRUD Operation을 정의한다.

Http Method	CRUD
POST	Create(Insert)
GET	Read(Select)
PUT	Update or Create
DELETE	Delete

	기존 게시판	RESTFul API를 지원하는 게시판
글읽기	GET /list.do?no=510&name=java	GET /bbs/java/510
글등록	POST /insert.do	POST /bbs/java/510
글삭제	GET /delete.do?no=510&name=java	DELETE /bbs/java/510
글수정	POST /update.do	PUT /bbs/java/510

기존의 게시판은 GET, POST로만 자원에 대한 CRUD를 처리하며, URI는 액션을 나타낸다.

RESTFUL 게시판은 4가지 메서드를 모두 사용하여 CRUD를 처리하며, URI는 제어하려는 자원을 나타낸다.

REST API를 통해 가져오는 결과값은 대부분 JSON을 통해 가져오는데 JSON에 대해 자세히 알고 싶으면 여기를 들어가서 보면 된다.

REST의 특징

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

REST 서버는 API만 제공, 클라이언트는 사용자 인증, 컨텍스트(세션, 로그인 정보)를 직접 관리하는 구조로 구분되기 때문에 서로 구현되어있는지 알 필요가 없고 '일관된 규칙'으로 서버와 클라이언트는 독립적인 개체이다.

2. 정형화된 인터페이스(Uniformed Interface)

2-1 리소스 식별 - URI(Unified Resource Indentity)

2-2 표현을 통한 리소스 처리 - HTML/JSON/XML

2-3 자기서술적 메시지 - 요청은 메시지 / 헤더의 메타데이터

3. 계층 시스템(Layered System)

REST API 서버는 비지니스 로직만 수행하고, 미들웨어를 통해 보안, 로드배런싱을 추가하여 구조상의 유연성을 들 수 있다.

4. 캐시(Cache)

HTTP 기존의 웹 표준을 그대로 사용하므로, 웹에서 사용하는 기존의 인프라를 그대로 활용 가능하다. HTTP 프로토콜 기반의 로드밸런서(mod_proxy)나, SSL은 물론이고 HTTP가 가진 가장 강력한 특징 중의 하나인 캐싱 기능을 적용할 수 있다. 일반적인 서비스에서 조회 기능이 주로 사용됨을 감안하면, HTTP 리소스들을 웹 캐쉬 서버 등에 캐싱하는 것은 용량이나 성능 면에서 이점이 있다. 캐싱 구현은 HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 가능하다.

5. 상태 없음(Stateless)

HTTP는 Stateless Protocol 이므로 REST 역시 무상태성을 갖는다. 즉 Session과 같은 정보를 따로 저장하지않고 관리하지도 않기 때문에 단순히 요청 들어오는 것을 처리하면 되고, 클라이언트의 상태를 관리할 필요가 없다.

6. Self-descriptiveness (자체 표현 구조)

동사(Method) + 명사(URI)로 이루어져 있어 어떤 메소드에 무슨 행위를 하는지 알 수 있다. 메시지 포맷 역시 JSON을 사용하여 직관적으로 이해가 가능한 구조로 REST API메시지만 보고도 이를 쉽게 이해할 수 있다.

ex)http://ktko.com/books/1/buy

REST API URI 식별자 설계 기본 원칙

1. 마지막 문자로 '/'를 포함하지 않는다. 슬래시(/)는 계층 관계를 나타내는데 사용한다.

(ktko.tistory.com과 ktko.tistory.com/)은 엄연히 다르다.

2. 가독성을 높이는 데에는 '-'를 사용한다.

3. 소문자만 사용

4. URI 에는 확장자를 넣지 않는다.

예를들어 .json, .xml, .csv라는 확장자를 넣으면 안된다.

header에 content Type이나 Accept에 확장자를 넣는다.