REST API란?

개요

---

 

나는 작년 12월 중순, 프로젝트를 진행하기 전까지 기능 구현과 서버 구축에 대해서 공부했다. 그런데 배우는 것까지는 좋았다. 그러나 배운 것을 '왜' 써야 하는지와 이것이 '무엇'인지에 대해 알지 못했다.

 

그렇기에 이번에는 내가 느낀 의문 중 하나인 REST API에 대해 간단히 알아보고자 한다.

 

 

 

REST? API?

---

 

먼저 API에 대해서 정리해보자.

 

API (Application Programming Interface)

프로그램을 작성하기 위한 일련의 부프로그램, 프로토콜 등을 정의하여 상호 작용을 하기위한 인터페이스를 말한다.

 

예를 들어 보자. 자신이 앱을 하나 만들었다. 이 앱은 날씨를 알려주는 서비스를 제공한다. 그런데 날씨에 대한 정보는 어디에서 받아올까? 현재로선, 스마트폰에 기상청에서 돌리는 슈퍼컴퓨터가 달려있어서 자체적으로 날씨 변화에 대한 연산이 가능할 리가 없다. 그러니 당연하게도 날씨에 대한 정보를 갖는 컴퓨터(서버)와 통신해서 가져온다.

하지만 위의 통신은 아무렇게나 해서는 안된다. 정해진 형식에 따라 요청을 보내야 한다. 이 형식을 지켜서 요청만 한다면 앱이든 웹이든 어느 환경이라도 원하는 데이터를 받아올 수 있다. 

 

또 다른 예를 들어보자. 특정인의 개인정보 요청을 보낸다고 가정해보자.

위의 아이콘(앱)은 이름과 순서, 기타 등등의 형식을 지켜서 보냈다. 아래  아이콘(웹)은 그러지 않았다.   

서로 다른 환경에서 요청을 보냄.

 

결과는 아래와 같다.

 

틀에 맞춘 올바른 요청만이 데이터를 가져올 수 있다.

 

 

 

 

REST

 

이미지 출처 : Medium

 

 

REST(Representational State Transfer)는 다음과 같은 의미를 갖는다.

1. 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하는 월드 와이드 웹과 분산 하이퍼 미디어 시스템을 위한 소프트웨어 아키텍쳐이다.
2. 네트워크 상에서 Server와 Client의 통신 방식 중 하나이다.

 

구글링에서는 더 나은 설명이 나온다.

 

REST는 자원 기반의 구조 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
자원은 이름으로 표현 및 구분하여 해당 자원의 상태( 정보 )를 주고 받는 모든 것을 의미한다. 이는 곧 '자원의 표현에 의한 상태 전달을 한다는 것'이다.

 

'자원'은 소프트웨어가 관리하는 모든 것( 이미지, 동영상, 텍스트, 숫자 또는 모든 유형의 데이터 )이고, '상태 전달'이란 JSON이나 XML로 데이터가 요청되는 시점에서 자원의 상태를 전달하는 것을 의미한다.

 

 

구체적인 개념을 보자.

HTTP URI( Uniform Resource Identifier )를 통해 자원(Resource)을 명시한다.
HTTP Method( POST, GET, PUT, DELETE, PATCH 등 )를 통해 해당 자원(URI)에 대한 
'CRUD Operation'을 적용한다.

 

 

REST의 특징

 

1. 균일한 인터페이스: URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다. 또한, HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다.
2. 무상태: 모든 클라이언트 요청은 이전 요청과 독립적으로 완료된다.
3. 계층화 시스템: 클라이언트는 다른 중개자에게 연결할 수 있으며, 서버는 요청을 다른 서버로 전달할 수 있다.
4. 캐시 가능성: 클라이언트 또는 중개자에 일부 응답을 저장하여 서버 응답 시간을 개선한다.
5. 온디맨드 코드: 서버는 클라이언트 기능을 확장하거나 사용자 지정할 수 있는 코드를 클라이언트에 전송한다.

결국 REST는 '하나의 지침'이다.

 

 

 

 

REST API

 

위와 같은 REST를 기반으로 서비스 API를 구축한 것이 REST API다.

 

REST API를 사용하면 다음과 같은 이점을 얻을 수 있다고 한다.

1. 확장성: 클라이언트-서버 상호 작용을 최적화하여 시스템 크기를 효율적으로 조정한다.
2. 유연성: 클라이언트와 서버를 완전히 분리하여 각 부분이 독립적으로 발전할 수 있게 한다.
3. 독립성: 사용되는 기술과 독립적이어서 다양한 프로그래밍 언어로 애플리케이션을 작성할 수 있다.

 

 

REST API의 기본적인 설계 규칙은 다음과 같다. 내용은 더 있으나 자세한 내용은 삼가하겠다.

 

• 도큐먼트는 객체 인스턴스나 데이터베이스 레코드와 같은 개념이다.
• 컬렉션은 서버에서 관리하는 디렉터리이다.
• 스토어는 클라이언트에서 관리하는 리소스 저장소이다.

 

• URI는 정보의 자원을 나타내야 한다.
  
  • 자원은 동사보다는 명사를 사용한다.
  • 자원은 대문자보다는 소문자를 사용한다.
  • 도큐먼트 이름으로는 단수 명사를 사용한다. 
  • 컬렉션이나 스토어 이름으로는 복수 명사를 사용한다.
    
    • 예) GET 일 때 : /Member/1 -> /members/1
  • 자원에 대한 행위는 HTTP 메소드(GET, PUT, POST, DELETE 등)로 표현한다.
    
    • URI에 HTTP 메소드가 들어가면 안 된다. 
      • 예) GET 일 때 : /members/delete/1 -> /members/1
    • URI에 행위에 대한 동사 표현이 들어가면 안 된다.
      
      • 예) GET일 때 :  /members/show/1 -> /members/1
    • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.
      
      • 예) id=12인 student 삭제일 때 :  /students/12

 

이렇듯 REST API는 메소드와 URI를 조합해서 일정한 정보와 작업을 요청하게 할 수 있는 특징을 지녔다.

 

더 자세한 내용은 AWS 사이트에서 볼 수 있다.

 

https://aws.amazon.com/ko/what-is/restful-api/

 

 

생각

---

 

요컨데, REST API는 편리하게 효율적으로 다양한 플랫폼과 상호작용할 수 있고, 정해진 틀에 따라 원하는 정보와 작업을 수행할 수 있기 때문에 사용하는 것이다. 물론 이 정보 전달 방식이 무조건적인 정답은 아닐 것이다. 상황에 따라 원하는 정보만 간편히 받을 수 있는 GraphQL 같은 방식도 채택해 사용할 수 있다. 어떤 것을 구현할지에 따라 최적을 고를 수 있어야 한다.

 

그런데 글을 쓰면서 문득 프로젝트 진행했을 때 스쳐지나간 생각이 다시금 떠올랐다. 백엔드 프레임워크도, 이번 주제인 REST API 같은 정보 전달 방식도 누군가가 체계적으로 만들어놨기 때문에 현재는 인터넷 서비스(소프트웨어)를 제작하는 시간이 이전보다 확연히 짧아졌다. 20여년 전보다 간단해졌고 간편해졌다. 이는 진입장벽이 낮아졌음을 시사한다고 생각한다. 덧붙여,  ChatGPT를 시작으로 점점 AI 서비스도 확장돼가고 있다. 특히 시시각각 발전하는 이 분야에서 인공지능 소프트웨어 엔지니어 Devin도 출시에 귀추가 주목되고 있다. 이런 발전 속도를 유지하면 앞으로 더욱 서비스 개발에 소요되는 시간이 단축돼서 일반인도 몇 번의 딸깍으로 일정 수준의 서비스 완성이 가능하지 않을까 싶다. 물론 유지 보수나 에러 해결은 제외하고 말이다.

 

언제나 영향력이 큰 변화를 접할 때마다 향후 미래를 거시적으로 보려고 애쓰고 있다. 부족한 통찰은 상상에 지나지 않지만 그래도 확신할 수 있는 것은 창의성과 추진력을 갖추든지, 나만의 특징적인 '무언가'를 만들든지 아니면 시대의 흐름에 따라갈 수 있고 어떤 변화에도 크게 영향이 없을 만큼 전문성을 갖춰야 한다고 생각한다.

 

무엇이 됐든, 변화에 적응하고 살아나갈 수 있는 한 명의 사회인이 되길 바라고 오늘도 열심히 살아가고자 한다.