RESTful API(Representational State Transfer)는 소프트웨어 아키텍처 스타일이며 네트워크 애플리케이션 설계를 위한 제약 조건 집합입니다. 주로 HTTP를 통신 프로토콜로 사용하여 클라이언트와 서버가 서로 상호 작용하는 방법을 정의합니다. RESTful API를 사용하면 클라이언트(예: 웹 브라우저 또는 모바일 앱)가 서버의 리소스(예: 데이터 개체 또는 서비스)에 액세스하고 조작할 수 있습니다.
다음을 포함하여 RESTful API에서 사용되는 몇 가지 표준 HTTP 메서드가 있습니다.
GET: 서버에서 리소스 또는 리소스 모음을 검색합니다.
POST: 서버에 새 리소스를 생성합니다.
PUT: 서버의 기존 리소스를 새 데이터로 업데이트합니다. 일반적으로 클라이언트는 전체 업데이트된 리소스를 보내야 합니다.
PATCH: 서버의 기존 리소스를 부분적으로 업데이트합니다. 클라이언트는 리소스를 업데이트하는 데 필요한 변경 사항만 보내야 합니다.
DELETE: 서버의 리소스를 삭제합니다.
이러한 메서드는 데이터 관리에서 일반적인 CRUD(Create, Read, Update, Delete) 작업에 해당합니다.
RESTful API는 몇 가지 주요 원칙을 따릅니다.
Stateless(무상태): 클라이언트에서 서버로의 각 요청에는 서버가 요청을 처리하는 데 필요한 모든 정보가 포함되어야 합니다. 서버는 요청 간에 클라이언트 상태에 대한 정보를 저장해서는 안 됩니다.
클라이언트-서버: 클라이언트와 서버는 네트워크를 통해 통신하는 별도의 엔터티입니다. 이러한 분리를 통해 유연성, 확장성 및 더 나은 문제 분리가 가능합니다.
캐시 가능: 클라이언트는 서버 응답을 캐시하여 성능을 개선하고 서버 로드를 줄일 수 있습니다. 응답은 캐시될 수 있는지 여부를 명시적으로 명시해야 합니다.
계층화된 시스템: 아키텍처는 여러 계층으로 구성될 수 있으며 각 계층은 특정 기능을 제공합니다. 이러한 모듈성은 관심사와 유연성의 분리를 촉진합니다.
"RPC 스타일" API(원격 프로시저 호출)라고도 하는 비 RESTful API는 REST 제약 조건 및 원칙을 준수하지 않습니다. 대신 클라이언트가 직접 호출할 수 있는 서버의 특정 기능이나 프로시저를 노출하는 데 중점을 두는 경우가 많습니다. 비 RESTful API의 몇 가지 예는 다음과 같습니다.
SOAP(Simple Object Access Protocol): XML을 사용하여 클라이언트와 서버 간에 구조화된 정보를 교환하는 프로토콜입니다. SOAP는 종종 웹 서비스와 연결되며 HTTP 또는 SMTP와 같은 다양한 전송 프로토콜을 사용할 수 있습니다.
XML-RPC: XML을 사용하여 호출을 인코딩하고 HTTP를 전송 메커니즘으로 사용하는 원격 프로시저 호출 프로토콜입니다. 이를 통해 클라이언트는 서버에서 메서드를 호출하고 XML 형식으로 응답을 받을 수 있습니다.
JSON-RPC: XML-RPC와 비슷하지만 데이터 직렬화에 XML 대신 JSON을 사용하므로 더 가볍고 읽기 쉽습니다.
이러한 각 비 RESTful API에는 장단점이 있으며 RESTful API와 비 RESTful API 간의 선택은 개발 중인 애플리케이션의 특정 요구 사항과 제약 조건에 따라 다릅니다.
