etc

# REST API란?

Tigercow.Door 2017. 11. 20. 18:31


안녕하세요. 문범우입니다.

최근 프로젝트를 진행하면서 REST API를 작성해야할 일이 생겼는데, 아무것도 모르던 상태에서 무작정 해보려니 너무 복잡해서 조금씩 정리해가면서 작성해보려 합니다.

먼저 REST API의 개념에 대해서 알아볼텐데, 잘못된 부분이 있거나 궁금하신 점에 대해서는 언제든지 댓글을 남겨주세요 :)


1. REST(Representational State Transfer)


먼저 REST에 대해서 알아보록 할게요.

많은 분들이 아래와 같은 소개로 시작을 하더군요 ㅎㅎ


REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다.

(출처: 위키피디아)


음.. 그렇다고 하네요!

위키피디아를 좀 더 살펴보면, 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이라고 합니다. 이때 네트워크 아키텍처 원리란? 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는 말입니다. 

즉, 웹 상의 자료를 HTTP위에서 SOAP(Simple Object Access Protocol)이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스입니다. 필딩의 REST 아키텍처 형식을 따르면, HTTP나 WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다고 합니다.

이런 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭됩니다. 



2. 기본 형태


우선, REST의 기본적인 내용들을 살펴볼게요!

REST의 요소로는 크게 메서드, 리소스, 메세지 3가지로 구성됩니다!

어떻게 구성된다는 것일까요?

예를 들어, "이름이 범우, 직업이 학생인 유저를 생성해"라는 호출이 있을 때

메서드는? "생성해"라는 행위가 되겠죠?

그리고 리소스는, "유저"로써 생성되는 것이며, 메세지는 "이름이 범우, 직업이 학생"이라는 것 입니다.

뒤에서 더 자세히 보겠지만, 위의 내용을 먼저 REST 형태로 표현해본다면,


HTTP POST , http://myblog/users/

{

"users":{

"name":"범우",

"job":"학생"

}

}


과 같이 표현될 수 있습니다.

첫번째 줄의, HTTP POST는 메서드가 되겠으며, 그 뒤에 http://myblog/users/ 라는 형태의 URI로써 리소스가 표현되고 생성되는 메세지는 그 아래 JSON 문서로 표현됩니다.

이제 메서드, 리소스, 메세지에 대해 대략적으로 이해가 가셨나요?

그럼 하나씩 더 깊이 살펴보도록 하겠습니다.



3. HTTP 메서드


REST 에서는 위에서 설명드린 것과 같이, 호출에서의 행위에 대한 메서드를 HTTP 메서드로 그대로 사용됩니다.

HTTP 에는 다양한 메서드가 존재한다고 하는데, REST에서는 단순히 CRUD(Create, Read, Update, Delete)에 해당하는 4가지 메서드만 사용합니다. 아래 표를 한번 확인해볼게요.


메서드

의미

멱등(Idempotent)

POST

Create

No

GET

Read(Select)

Yes

PUT

Update

Yes

DELETE

Delete

Yes


처음에 이야기 한 것 처럼, REST에서는 CRUD에 해당하는 4가지 메서드를 사용합니다.

POST, GET, PUT, DELETE의 메서드가 각각의 의미와 해당하며 추가적으로 멱등(Idempotent)라는 항목이 나와있는데, 멱등이라는 것은 '수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러번 적용하더라도 결과가 달라지지 않는 성질' 이라고 합니다.

즉, 어떤 행위(메서드)를 여러번 수행했을 때 결과가 바뀌는지에 대한 개념입니다. POST 메서드의 경우 특정 리소스를 추가하는 행위이기 때문에 Idempotent하지 않지만, 나머지 GET, PUT, DELETE는 반복적으로 여러번 수행해도 Idempotent합니다. 하지만 블로그에서 어떤 글을 읽었을 때 조회수가 증가하는 기능이 있다면, GET 메서드 호출이 있을 때 조회수의 변화가 있기 때문에 Idempotent하지 않다고 볼 수 있습니다.


멱등(Idempotent)라는 개념을 설명드리는 이유는, 뒤에서 알아볼테지만, REST는 각 개별 API를 상태 없이 수행하게 됩니다. 그래서 해당 REST API를 다른 API와 함께 호출했다가 실패한 경우, 트렌젝션 복구를 위해 다시 호출을 해야 하는 경우가 있는데, 이때 Idempotent 한 메서드의 경우 단순히 반복적으로 메서드를 수행하면 되겠지만 Idempotent 하지 않은 메서드의 경우 기존의 상태를 저장했다가 다시 수행해야 하는 문제가 있습니다.



4. 리소스


REST는 모든 것을 리소스로 표현합니다. 리소스로 표현한다는 것은 간단히 말해서 명사로 표현한다는 것입니다. 그리고 세부적인 리소스는 id 붙여서 표현합니다.

즉, 사용자(유저)라는 리소스 타입을 정의한다면, http://myblog/users 라고 정의될 것이고 이에 따라 범우라는 id를 갖는 리소스는 http://myblog/users/범우 로 정의될 것입니다.

그런데 이러한 리소스가 명사로써 표현이 되다보니 명령, 행위와 같은 동작들은 API를 정의할 때 헷갈릴 수 있습니다.

예를 들어, "Check 메세지를 보내" 라는 호출이 있을 때는 어떻게 해야 할까요?

위의 형태를, "Check 메세지 요청을 생성해" 라는 형태로 변경해본다면, API 포맷은 POST/myblog/check 와 같은 형태가 될 수 있습니다.



5. REST API 예제


그럼, 위에서 알아본 내용들을 통해 간단한 REST API 예제를 살펴보도록 하겠습니다.


5-1. 생성(Create)


HTTP POST, http://myblog/users/

{

"name":"범우",

"job":"학생"

}


위의 형태는, http://myblog/users/ 라는 리소스를 이름은 범우, 직업은 학생이라는 메세지로 HTTP Post를 이용하여 생성하는 것입니다.



5-2. 조회(Read)


HTTP GET, http://myblog/users/범우


위의 형태는 http://myblog/users/ 라는 유저 리소스에서 이름(id)이 범우인 유저의 정보를 조회하는 것입니다.



5-3. 업데이트(Update)


HTTP PUT, http://myblog/users/범우

{

"name":"범우",

"job":"백수"

}


위의 형태는, http://myblog/users/ 라는 유저 리소스에서 이름(id)이 범우인 유저의 직업을 백수로 바꾸는 것입니다.



5-4. 삭제(Delete)


HTTP DELETE, http://myblog/users/범우


마지막으로 위의 형태는, http://myblog/users 라는 유저 리소스에서 이름(id)이 범우인 정보를 삭제하는 것입니다.



이렇게 해서 REST API에 대해 기본적인 것들을 알아보았습니다.

설명이 잘못 되었거나, 궁금하신 점은 언제든 댓글을 남겨주세요 :)

728x90