독립된 애플리케이션 간의 통신을 위해서는 매개체가 필요하다.그래서 개발자들은 종종 한 애플리케이션에서 다른 애플리케이션에서 제공하는 정보 또는 기능에 접근할 수 있도록 하는 매개체 - Application Programming Interfaces(API)를 구축한다.
애플리케이션을 대규모로 신속하게 통합하기 위해서, API는 프로토콜 그리고/또는 사양을 사용하여 통신간 사용하는 메시지의 의미와 구문을 정의한다. 이러한 프로토콜 그리고/또는 사양이 API 아키텍처를 구성한다.
시간이 지남에 따라, 다양한 API 아키텍처 스타일이 새롭게 정의되고 있다. 각각의 API 아키텍처 스타일은 고유의 표준화된 데이터 교환 절차를 가지고 있다. 이러한 상황은 어떤 API 아키텍처 스타일이 가장 좋은지에 대한 끝없는 논쟁을 야고하고 있다.
요즘 많은 API 개발자들은 REST API를 '한물 간'(말장난은 살리지 못 한 것으로...)것으로 여기며 GraphQL에 대한 지지를 보내고 있지만, 이 현상은 10여년 전 REST를 SOAP를 대체하는 승자로 여겨지던 상황과 매우 유사하다. 이러한 인식의 문제는 "기술이 지닌 속성과 특성이 직면하고 있는 문제와의 관계"를 고려하지 않고 단순히 기술 자체를 선택하고 있다는 사실이다.
이 포스트에서는 객관적인 입장에서 네 가지 주요 API 스타일의 등장 순서대로, 각 스타일의 장점과 단점을 비교하고 활용되기 가장 좋은 시나리오를 소개할 것이다.
참조: https://www.altexsoft.com/blog/soap-vs-rest-vs-graphql-vs-rpc/
