이전에 작성했던 Google Maps API도 그렇고, 웹 프로젝트를 개발했을 때도 그렇고, 항상 API를 사용했던 기억은 있으나 개념에 관한 것은 정확히 알지 못하고 사용할 때, 과제로 REST API에 대한 보고서를 작성하라는 내용이 나와 개념에 대해 조금이라도 정확히 알고 가고자 이 글을 작성한다.
REST API를 설명하기에 앞서, 뒤에 있는 'API'는 무엇을 의미하는 것일까?
Application Programming Interface
응용 프로그램 프로그래밍 인터페이스
개발자가 프로그래밍을 할 때, 프로그램을 작성하기 위해 사용되어지는 프로그래밍을 일컫는다. 이렇게 딱딱하게 설명하면 알아듣기 힘드니 예시를 지어 설명하자면,
printf("안녕하세요"); // C
print("안녕하세요") # Python
이렇게 문자열을 출력할 때, API가 없었다면 printf, print 와 같은 간단한 명령으로 처리하는 것이 아니라 개발자가 직접 저수준의 공간으로 들어가 컴퓨터 메모리를 건드려야 하는, 굉장히 큰 불편함을 겪었을 것이다.
작업의 과정들이 모두 저수준으로 수행될 때, API가 언어에 맞게 추상화하고, 개발자가 손쉽게 제어할 수 있게끔 도와주는 역할을 맡게 된다.
🤪 API가 없었다면 개발자의 인구는 반의 반의 반으로 줄었을 것
API를 간략적으로 살펴보았으니, 이제는 REST API에 대해 알아보도록 하자.
API 사용이 주로 프로그램의 내부에서 이루어지는 것은 어떻게 보면 당연한 이치였다. 하지만 이 이치를 깨고 다양한 분야에 사용할 수 있도록 이끈 것이 로이 필딩이었다.
로이 필딩은 HTTP의 주요 저자 중 한 사람으로서, 당시 HTTP가 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습을 바라보며 웹의 장점을 최대한 활용할 수 있는 REST를 발표하게 된다.
HypterText Transfer Protocol
웹 상의 텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로, 서버와 클라이언트가 어떻게 메세지를 교환할지 정해놓은 규칙을 의미한다.
REST API를 자세히 알아보기 전 우리가 중요하게 알아두어야 할 것은, HTTP의 구조는 Request(요청) 와 Response(응답) 로 구성되어 있다는 것이다.
또한, 서버에 REST API로 Request를 보낼 때 사용하는 HTTP 메소드는 POST, GET, PUT, DELETE, PATCH 등이 있다. 자세한 내용은 밑에서 알아보도록 하자.
HTTP URI(Uniform Resource Identifier)를 통해 Resource(자원)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
REST API는 자원 기반의 구조 설계의 중심에 Resource(URI)가 있고, HTTP 메소드를 통해 Resource 를 처리하도록 설계된 아키텍처이다.
추가로, RESTful API 라는 용어가 있는데, 공식적으로 발표한 용어는 아니고 개발자들이 비공식적으로 의견을 제시한 것이라 명확한 정의는 없다. 보통은, 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 의미한다.
대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create, Read, Update, Delete + (Patch) 를 묶어서 일컫는 말이다.
REST API에서는 POST, GET, PUT, DELETE, PATCH 메소드를 통해 CRUD를 실행하며 Resource 를 처리한다.
POST, PUT, PATCH에는 body가 존재해서 GET, DELETE 에 비해 정보들을 더 많이, 그리고 더 안전하게 보낼 수 있다.
🙋 "PUT과 PATCH는 모두 수정인데 무슨 차이야?"
PUT은 정보를 통째로 수정할 때 주로 사용하고, PATCH는 정보 중 일부를 수정할 때 주로 사용하는 것으로 알고 있으면 된다.
🙋 "Idempotent?"
계속해서 수행을 해도 결과가 같은 경우를 의미한다. POST 메소드의 경우 Resource 를 계속해서 생성하는 연산이기 때문에 결과가 늘 다르고, 나머지는 계속해서 수행해도 결과가 같다.
이 때 주의할 점은, GET 메소드의 경우 게시물의 조회수 카운트를 늘려주는 것과 같은 기능을 수행했을 땐 당연히 결과가 늘 달라지니 Idempotent 하지 않은 메소드로 정의해야 하는 것이 옳다.
결과가 늘 같은 메소드들은 복구할 때 반복적으로 다시 메소드를 수행하면 되지만, 결과가 늘 다른 메소드의 경우 기존의 상태를 저장했다가 원복 해야 하는 문제가 있다.
사실, POST만으로도 데이터를 작성하고, 읽고, 삭제하고, 수정하는 작업을 모두 수행할 수 있다. 하지만 개발은 혼자하는 것이 아니고, 언제든지 다른 개발자들에게 인계할 수 있기 때문에 누구든 각 요청의 의도를 쉽게 파악할 수 있도록 하는 것이 중요하다. 그렇기에 이들은 목적에 따라 구분해서 사용해야 한다.
유니폼 인터페이스(Uniform Interface)
REST API는 표준을 지킨다면, 어떤 기술이든지 사용이 가능한 인터페이스 스타일이다. HTTP + JSON 으로 REST API를 정의했다면, C든, JAVA든 언어에 종속 받지 않고 HTTP + JSON 사용이 가능하다.
무상태성(Stateless)
작업을 위해 상태 정보를 따로 저장하고, 관리하지 않음을 의미한다. 그렇기 때문에 API 서버는 들어오는 요청만 단순하게 처리하게 되면서, 서비스의 자유도가 높아지고 구현이 단순해지는 효과를 얻게된다.
캐시 가능(Cacheable)
HTTP 라는 기존의 웹 표준을 그대로 사용하기 때문에, HTTP가 가진 가장 강력한 특징 중 하나인 캐시 기능을 적용할 수 있다. 대량의 요청을 효율적으로 처리할 때 캐시가 요구되는데, 캐시 사용을 통해 응답 시간이 빨라지는 효과를 기대할 수 있게 된다.
자체 표현 구조(Self-descriptiveness)
REST API 메세지만 보고도 쉽게 이해할 수 있는 구조로 구성되어 있다.
서버-클라이언트 구조(Server-Client)
자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트가 된다. 당연한 개념이지만[..] 역할이 확실하게 구분되며 클라이언트와 서버에서 개발해야 할 내용이 명확해지고, 서로의 개발에 있어 의존성이 줄어들며 개발자에게 편리함을 제공한다.
사용할 수 있는 메소드가 별로 없고, 표준이 존재하지 않는다는 단점이 있다.
URI는 정보의 Resource를 표현해야 한다.
예) PUT 도메인/classes/2/students
◆ Resource 를 표현할 때 동사는 사용하지 않는다.
예) POST 도메인/classes/2/students/insert (X)
◆ Resource 의 컬렉션, 스토어 이름으로 복수 명사를 사용한다.
예) PUT 도메인/class/2/student (X)
Resource에 대한 행위는 HTTP Method 로 표현한다.
예) PUT 도메인/classes/2/students/14
◆ Resource에 HTTP Method가 들어가는 것을 허용하지 않는다.
예) PUT 도메인/classes/2/students/14/update (X)
혼동 방지를 위해 URI 마지막 문자로 슬래시(/)를 포함시키지 않는다.
예) POST 도메인/classes/2/students/ (X)
가독성을 위해 밑줄(_)은 URI에 사용하지 않는다.
URI 경로에는 소문자 사용을 권장한다.
파일 확장자는 URI에 포함시키지 않는다.
예) 도메인/members/soccer/345/photo.jpg (X)
예) 도메인/members/soccer/345/photo HTTP/1.1 Host: 도메인 Accept: image/jpg (O)
리소스간 관계를 표현할 땐 두 가지 방법을 사용한다.
예) Get : /users/teddy/devices
예) Get : /users/teddy/likes/devices (관계를 명시적으로 표현)
참고 및 출처
REST란? REST API란? RESTful이란?
REST API 제대로 알고 사용하기
REST API의 이해와 설계-#1 개념 소개
위키백과 : CRUD
REST API가 뭔가요?(youtube)