안녕하세요 오늘은 REST API 에 대해서 알아보겠습니다. 얼마전 면접을 봤는데, 이 때 REST API가 무엇인지에 대한 질문에 대해 제대로된 답변을 하지 못해 찾아봤어요. 그럼 이제 시작해볼까요?
REST API란 'Representational State Transfer' 의 약자로 웹 서비스를 구축하기 위한 규칙의 집합이에요. World Wide Web의 기반이 되는 HTTP 프로토콜을 기반으로하며, GET, POST, PUT, DELETE 및 PATCH와 같은 HTTP 메서드와 함께 작동하도록 설계되었어요.
REST API는 개발자가 접근하고 상호작용할 수 있는 endpoint의 집합 또는 URLs 를 정의해요. 각 endpoint 는 일반적으로 사용자 또는 사용자 목록과 같은 특정 리소스 또는 리소스 모음을 나타내요. Endpoint 는 URL 패턴이라는 특정 syntax를 사용해서 정의되고, 이를 통해 개발자는 예측가능하고 일관적인 방식으로 필요한 리소스에 접근할 수 있어요. 다시 정리하면 HTTP URI(Uniform Resource Identifier)를 통해 리소스(자원)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 리소스에 대한 CRUD Operation을 적용하는 아키텍쳐를 의미해요.
HTTP Method를 사용하여 CRUD 구현
| Method | Action | 역할 | 페이로드 |
| GET | index/retrieve | 모든/특정 리소스를 조회 | X |
| POST | create | 리소스를 생성 | O |
| PUT | replace | 리소스의 전체를 교체 | O |
| PATCH | modify | 리소스의 일부를 수정 | O |
| DELETE | delete | 모든/특정 리소스를 삭제 | X |
REST API는 HTTP status code 들을 사용해서 request에 대한 성공 혹은 실패를 나타내요. 예를 들어 status code 200은 request가 성공했음을 나타내며, 404는 request 에 대한 리소스를 찾을 수 없음을 의미해요.
RESTful API는 또한 HTTP header 를 사용하여 request 또는 response 대한 추가적인 정보를 전달해요. 예를 들어 Content-Type header는 데이터가 보내질 때 어떠한 형식(JSON 또는 XML)으로 전달되는지에 대한 데이터의 형식을 나타내는데 사용해요.
REST API 의 구성 요소로는 리소스, 행위(Verb), 표현(Representation of Resource)이 있어요. 먼저 리소스에 대해 알아볼까요?
모든 리소스에는 고유한 ID가 존재하고(리소스를 구별하는 ID를 URI 라고 해요. '/window/:window_id' 와 같은 HTTP URI 에요), 리소스는 server에 존재합니다.
행위(Verb)는 HTTP 프로토콜의 메소드를 사용해요. HTTP 프로토콜은 위에서도 말한 것처럼 GET, POST, PUT, DELETE 와 같은 메서드를 제공해요.
마지막으로 표현(Representation of Resource)을 알아볼게요. 사용자가 리소스에 대한 조작을 요청(request) 하면 server는 이에 대한 적절한 응답(response)를 보내는데, 이때 응답에 해당하는 내용이 표현이에요. REST 에서는 하나의 리소스가 JSON, XML, TEXT, RSS 등 여러 형태의 표현(Representation)으로 나타내어 질 수 있어요. 보통은 JSON 또는 XML을 사용하기는해요.
REST API의 구성
| 구성요소 | 내용 | 표현 방법 |
| Resource | 리소스(자원) | HTTP URI |
| Verb | 리소스에 대한 행위 | HTTP Method |
| Representation | 지소스 행위에 대한 내용 | HTTP Message Pay Load |
REST API의 특징으로는 Server-Client(서버-클라이언트 구조), Stateless(무상태), Cacheable(캐시 처리 가능), Layered System(계층화), Code-on-Demand 그리고 Uniform Interface 등이 있어요.
먼저 Server-CLient(서버-클라이언트 구조)에 대해서 알아볼게요. 이는 말 그대로 Server에는 리소스가 존재하고, Client는 리소스를 요청(request) 하는 구조를 가지는 것을 의미해요. 이렇게 분리하면 서로 간 의존성이 줄어든다는 장점이 있어요.
다음으로 Stateless(무상태)는 Client의 context를 Server에 저장하지 않는 것을 의미해요(세션과 쿠키 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해져요). 당연히 HTTP 프로토콜은 기본적으로 stateless 프로토콜이므로 REST도 이러한 특징을 따르게 되는거에요. 이러한 특징으로 Server는 각 요청(request)을 완전히 별개의 것으로 인식하고 처리하게 되어요. 그러면 각 API server는 Client의 요청(request)만을 단순 처리해요(단순 처리라는 의미는 server가 client의 이전 요청과 연관된 처리를 하지 않는다는 의미에요). 이렇게하면 server의 처리 방식에 일관성을 부여할 수 있고, 부담이 줄어들며 서비스의 자유도가 높아져요.
이번에는 Cacheable(캐시 처리 가능)에 대해서 알아볼게요. REST를 사용하면 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹기능을 사용할 수 있고, HTTP가 가진 캐싱 기능을 적용할 수 있어요. 대량의 요청(request)을 효율적으로 처리하기 위해 캐시가 사용되는데, 이러한 캐시 사용을 통해 응답(response)이 빨라지고, server 트랜잭션이 발생하지 않으므로 전체 응답시간(response time), 성능, 서버의 자원 이용률과 같은 것을 향상시킬 수 있어요.
REST API의 특징 중 Layered System(계층화)가 존재해요. REST API의 Server는 계층적으로 구성될 수 있어요. API Server는 순수 비즈니스 로직만 수행하고, 그 앞든에는 보안, 로드밸런싱, 사용자 인증 등을 추가해서 구조상 유연성을 줄 수 있어요. 또한 로드밸런싱, 공유 캐시 등을 사용해서 확장성과 보안성을 향상시킬 수도 있답니당.
Code-On-Demand는 REST API 가 꼭 지켜야하는 특징은 아니에요. Server로부터 스크립트를 받아서 Client에서 실행하는 것을 의미해요.
마지막으로 Uniform Interface(인터페이스 일관성)을 지키는 특징이 있어요. URI를 통해 특정 리소스들에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 것을 의미해요. 이러한 특징 때문에 HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능해요. 당연히 모바일 환경에서도 사용이 가능하게 되겠죠?
이렇게 여러가지를 어렵게(?) 말했지만 결국 REST API에서 가장 중요한 것은 두 가지에요. 첫 번째는 URI는 리소스를 표현하는 것에만 집중하고, 두 번째는 행위(Verb)에 대한 정의는 HTTP Method를 통해 하는 것이에요. 이 두 가지 특징이 REST API를 설계하는 중심 규칙이에요.
REST API는 모바일 앱, 웹 애플리케이션 그리고 IoT 장치를 비롯한 다양한 애플리케이션 웹 서비스를 구축하는데 널리 사용해요. 또한 사용하고 이해하기 쉬워 개발자들 사이에서 인기가 많아요. 이렇게 REST API에 대해서 알아봤어요. 다음에는 제대로된 답변을 할 수 있겠죠? 그럼 우리 다음에 만나요~