주니어 프론트엔드 개발자가 정리한 REST API

dev.tinkerbell·2020년 12월 15일

정적 웹사이트만 만들다가 API라는 개념을 접하면서 REST API의 개념도 같이 접했다. 그때 당시 정확한 개념보단 "서버와 클라이언트에서 리소스를 요청하고 얻는다" 정도로의 개념으로만 알고 사용했고 프로젝트를 진행했었다. 그러던중 강사님께서 그런 REST API로 괜찮은가라는 영상을 추천해주셨고 REST API에 대해 다시 한번 생각해보게 되었다.

패스트캠퍼스 프론트엔드 스쿨 마지막 프로젝트를 끝낸 시점에서 제일 기억에 남았던 부분 중 하나가 API를 설계하고 수정했던 것인데 그 전까진 서버개발자들의 담당이라고만 생각했던 부분이 직접 만들고 난 후에 나는 아직도 이 개념에 대해 잘 모르고 있다는 생각이 들었고 그와 동시에 API와 REST API가 무엇인지 정확히 설명할 수 없는 나와 같은(?) 개발자가 많다고 생각했다.

이 기회를 통해 공부하면서 정리하려고 한다.

📍어이어이 REST API라고 들어봤나?

개발자인데 REST API에 대해 정확한 개념으로 설명할 수 없다고 하지만 들어보지 못했다는 개발자는 없을 것이다. 그만큼 개발자에게 중요하다고 생각하는 개념이고 주니어 프론트엔드 개발자라면 면접 질문 중 한번쯤 들어봤을 필수 질문 중 하나이다.

"REST API"에 대해 설명해주세요.

만약 이 개념에 대해 정확히 모르고 있다면..?

당연히 어버버버버 하고 나오겠지.. 생각만해도 끔찍하다. 개념을 정확히 다 알아야 한다고 생각하진 않지만 적어도 내가 어떤걸 사용하고 왜 사용하고 있는지는 알아야 하지 않을까? 하나하나 천천히 생각해보자. 매우 어렵지만은 않을 것이다. 다 사람이 생각했는걸~

그럼 API는 설명해줄 수 있어요..? 🧐

스스로 생각하고 답했을때 매끄럽게 설명할 수 있는 주니어 개발자는 몇 없을 것 같다.
나는 API를 매 프로젝트에서 아이디어 회의를 할때 언급되었다. 음악 어플이나 날씨 어플 등을 만들고자 할때 그에 관한 데이터 또는 기능이 필요로 했고 그것을 두고 "음악 관련 API가 필요하다" 또는 "날씨 관련 API가 필요하다"라고 얘기했다. 하지만 정확히 API가 무엇인지 물었을때 나는 확답을 하지 못했다. 그러므로 다시 하나씩 찾아보자. 위키백과에서의 API는 뭐라고 설명할까?

API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.
API 위키백과

이해가 가는가?? 나는 솔직히 읽고 이해가 가지 않았다. 응용 프로그램 프로그래밍 인터페이스. 일단 인터페이스의 개념이 정확히 와닿지 않았다. 그래서 또 찾아보았다.

인터페이스(interface)는 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다. 컴퓨팅에서 컴퓨터 시스템끼리 정보를 교환하는 공유 경계이다. 이러한 교환은 소프트웨어, 컴퓨터 하드웨어, 주변기기, 사람 간에 이루어질 수 있으며, 서로 복합적으로 이루어질 수도 있다. 터치스크린과 같은 일부 컴퓨터 하드웨어 장치들은 인터페이스를 통해 데이터를 송수신할 수 있으며 마우스나 마이크로폰과 같은 장치들은 오직 시스템에 데이터를 전송만 하는 인터페이스를 제공한다.
인터페이스 위키백과

조금 더 풀어서 생각해보자면 인터페이스는 어떠한 두가지의 관계에서 상호간 소통할때의 매개체라고 이해했다. 다양한 관계가 있겠지만 마우스 예를 들어보면 사용자가 인터넷 아이콘을 클릭하고 싶을때 마우스를 이용하여 클릭을 하게 된다. 이때, 마우스는 사용자와 인터넷 사이에서의 신호를 주고 받을 수 있게 하는 매개체이다. 즉 이 관계에서 마우스는 인터페이스이다.

이러한 개념으로 생각해보았을 때 다시 위키백과에서 설명한 것을 참조해보자면, "응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다." 라고 했다.
즉, 내가 만드는 프로그램(응용 프로그램)에서 누군가가 만든 기능(운영체제나 프로그래밍 언어가 제공하는 기능)을 제어할 수 있게 하는 매개체가 API라고 설명할 수 있다.

REST API를 설명해보자 😤

와.. REST API를 위해 먼 길을 돌아왔다. 그래도 API의 개념을 알았으니 됐다. 그럼 REST가 무엇인지 알아볼까?

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다.
REST 위키백과

위키백과의 설명을 보고도 잘 이해가 가지 않아 REST를 설명한 사이트들을 참조했다. 참조한 내용을 바탕으로 풀어보자면 REST는 HTTP기반으로 필요한 자원에 접근하는 방식을 정해놓은 아키텍쳐라고 한다.

결국 W3상에서 정보를 주고받을 수 있는 프로토콜을 잘 활용하지 못하는 개발자들을 안타까워하며 로이 필딩이 직접 나서서 REST를 발표한 것이다. 그럼 REST를 사용하면서 어떠한 장점과 속성이 있고 구성요소가 어떻게 구성 되어 있는지 알아보자.

REST의 장점

특정 요구 사항이 있는 SOAP(Simple Object Access Protocol)등의 규정된 프로토콜보다 사용하기 쉽고 속도가 빠르다.

REST의 속성

서버에 있는 모든 resource는 각 resource 당 클라이언트가 바로 접근 할 수있는 고유 URI가 존재한다.
모든 요청은 클라이언트가 요청할 때마다 필요한 정보를 주기 때문에 서버에서는 세션 정보를 보관할 필요가 없다. 즉, 서비스에 자유도가 높아지고 유연한 아키텍쳐 적응이 가능하다.
HTTP 메소드를 사용한다. 모든 resource는 일반적으로 HTTP 인터페이스인 GET,POST,PUT,DELETE 4개의 메소드로 접근 되어야 한다.
서비스 내에 하나의 resource가 주변에 연관 된 리소스들과 연결되어 표현이 되어야 한다.

REST의 구성 요소

REST는 자원(Resource), 메소드(Method), 메세지(Message) 세 가지로 구성되어 있다.

자원(Resource)

REST는 자원에 접근하는 방식을 정해놓은 아키텍쳐라고 했다. 그럼 자원에 어떻게 접근해야할까?
REST에서는 자원의 위치를 나타내는 URI(Uniform Resource Identifier)로 접근한다. 또한 URI를 설계시 지켜야하는 규칙이 있다.

/의 쓰임새
/는 계층 관계를 나타내는데 사용함으로 URI 마지막 문자로 /를 포함하지 않는다.
URI를 이루는 resource들은 동사보단 명사로 이루어져 있어야 한다.
자원의 정보를 표현해야 하는 URI는 PUT, POST 등 행위보다 자원의 표현으로 구성되어야 한다.
URI에서는 _보다 -을 권장한다.
URI를 쉽게 읽고 해석하기 위해 밑줄 때문에 문자가 가려지기도 하는 문제점을 해소한다.
URI 경로에는 소문자가 적합하다.
URI 문법 형식은 URI 스키마와 호스트를 제외하고 대소문자에 따라 다른 리소스로 인식한다.
파일 확장자는 URI에 포함시키지 않는다.
Accept header를 사용한다.

메소드(Method)

자원에 접근할 때 어떤 행위로 요청인지 HTTP 메소드가 알려준다. GET, PUT, POST, DELETE를 사용하며 이것으로 CRUD를 구현한다.

Method	역할
GET	해당 리소스를 조회한다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
PUT	해당 리소스를 수정한다.
POST	해당 URI를 요청하면 리소스를 생성한다.
DELETE	해당 리소스를 삭제한다.

Endpoint
메소드는 같은 URI들에서도 다른 요청을 하게끔 구별해주는 항목이 있다. 예를 들면
GET /user/books/1
POST /user/books/1
DELETE /user/books/1
세 가지의 URI가 같더라도 메소드에 따라 다른 요청을 할 수 있으며 이것을 Endpoint라고 한다.

결론

REST API는 HTTP기반으로 필요한 리소스를 요청하는 아키텍처로 설계된 어플리케이션 프로그래밍 인터페이스이다.

아니 잠깐만 GraphQL도 묶어서 많이 보이던데? 🤪

GraphQL은 Graph Query Language의 약어로서 REST API의 단점을 보안하고자 나왔다.

REST API 단점

REST API로는 다양한 기종에서 필요한 정보들을 일일히 구현하는 것이 힘들었다.

GraphQL과 RESTful의 차이점

HTTP 요청 회수를 줄일 수 있다.
GraphQL은 원하는 정보를 하나의 Query에 담아 요청하는 것이 가능하기 때문에 리소스 종류 별로 요청하는 REST보다 HTTP 요청 회수를 줄일 수 있다.
HTTP응답의 사이즈를 줄일 수 있다.
GraphQL은 원하는 대로 정보를 요청하는 것이 가능한 반면 REST는 응답의 형태가 정해져 있고 필요한 정보만 부분적으로 요청하는 것이 힘들다.