REST API(RESTful API 또는 RESTful 웹 API라고도 함)는 REST(Representational State Transfer) 아키텍처 스타일의 설계 원칙을 준수하는 API(애플리케이션프로그래밍 인터페이스)입니다. REST API는 애플리케이션을 통합하고 마이크로서비스 아키텍처의 구성 요소를 연결하는 유연하고 가벼운 방법을 제공합니다.
2000년 컴퓨터 과학자 Roy Fielding 박사가 박사 학위 논문에서 처음 정의한 REST는 개발자에게 비교적 높은 수준의 유연성, 확장성 및 효율성을 제공합니다. 이러한 이유로 REST API는 마이크로서비스 아키텍처에서 구성 요소와 애플리케이션을 연결하는 일반적인 방법으로 부상했습니다.
본 eBook은 관측 가능성을 둘러싼 오해를 바로잡고 디지털 세계에서 관측 가능성의 역할을 보여주는 것을 목표로 합니다.
지능형 자동화 가이드 읽기
동일한 리소스에 대한 모든 API 요청은 요청의 출처에 관계없이 동일하게 표시되어야 합니다. REST API는 사용자의 이름 또는 이메일 주소와 같은 동일한 데이터가 하나의 URI(Uniform Resource Identifier)에만 속하도록 해야 합니다. 리소스가 너무 커서는 안 되며 클라이언트가 필요로 할 수 있는 모든 정보를 포함해야 합니다.
REST API 설계에서 클라이언트 및 서버 애플리케이션은 서로 완전히 독립적이어야 합니다. 클라이언트 애플리케이션이 알아야 하는 유일한 정보는 요청된 리소스의 URI입니다. 서버 애플리케이션과 다른 방법으로 통신할 수 없습니다. 마찬가지로 서버 애플리케이션은 HTTP를 통해 요청된 데이터에 클라이언트 애플리케이션을 전달하는 것 외에는 클라이언트 애플리케이션을 수정해서는 안 됩니다.
REST API는 무상태성이기 때문에 각 요청에는 처리에 필요한 모든 정보가 포함되어야 합니다. 즉, REST API에는 서버 측 세션이 필요하지 않다는 의미입니다. 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없습니다.
가능한 경우 클라이언트나 서버 측에서 리소스를 캐시할 수 있어야 합니다. 서버 응답에는 전달된 리소스에 대해 캐싱이 허용되는지 여부에 대한 정보도 포함되어야 합니다. 목표는 클라이언트 측의 성능을 향상시키는 동시에 서버 측의 확장성을 높이는 것입니다.
REST API에서는 호출과 응답이 서로 다른 계층을 거칩니다. 일반적으로 클라이언트와 서버 애플리케이션이 서로 직접 연결된다고 가정하지 않습니다. 통신 루프에는 다양한 중개자가 있을 수 있습니다. REST API는 클라이언트나 서버가 최종 애플리케이션과 통신하는지 중개자와 통신하는지 알 수 없도록 설계해야 합니다.
REST API는 일반적으로 정적 리소스를 전송하지만 경우에 따라 응답에 실행 코드(예: Java 애플릿)가 포함될 수도 있습니다. 이러한 경우 코드는 온디맨드 방식으로만 실행되어야 합니다.
REST API는 HTTP 요청을 통해 통신하여 리소스 내에서 레코드를 생성하고 읽기, 업데이트 및 삭제(CRUD라고도 함)와 같은 표준 데이터베이스 기능을 수행합니다.
예를 들어 REST API는 GET 요청을 사용하여 레코드를 검색합니다. POST 요청은 새 레코드를 생성합니다. PUT 요청은 레코드를 업데이트하고 DELETE 요청은 레코드를 삭제합니다. API 호출에는 모든 HTTP 방식를 사용할 수 있습니다. 잘 설계된 REST API는 HTTP 기능이 내장된 웹 브라우저에서 실행되는 웹 사이트와 유사합니다.
특정 순간 또는 타임스탬프의 리소스 상태를 리소스 표현이라고 합니다. 이 정보는 JSON(JavaScript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트를 포함한 거의 모든 형식으로 클라이언트에 전달될 수 있습니다. JSON은 사람과 기계 모두 읽을 수 있고 프로그래밍 언어에 구애받지 않기 때문에 널리 사용됩니다.
요청 헤더 및 매개 변수는 메타데이터, 권한 부여, URI(Uniform Resource Identifier), 캐싱, 쿠키 등과 같은 중요한 식별자 정보를 포함하기 때문에 REST API 호출에서도 중요합니다. 요청 헤더 및 응답 헤더는 기존 HTTP 상태 코드와 함께 잘 설계된 REST API 내에서 사용됩니다.
유연성은 REST API 설계의 큰 장점이지만 유연성으로 인해 결함이 있거나 성능이 떨어지는 API를 쉽게 설계할 수도 있습니다. 이러한 이유로 전문 개발자는 REST API 사양의 모범 사례를 공유합니다.
OAS(OpenAPI 사양)는 모든 개발자나 애플리케이션이 API를 발견하고 그 매개변수와 기능을 완전히 이해할 수 있는 방식으로 API를 설명하는 인터페이스를 설정합니다. 이 정보에는 사용 가능한 엔드포인트, 각 엔드포인트에서 허용되는 작업, 작업 매개변수, 인증 방법 등이 포함됩니다. 최신 버전인 OAS3에는 다양한 프로그래밍 언어로 API 클라이언트와 서버 스텁을 생성하기 위한 OpenAPI Generator와 같은 실무 도구가 포함되어 있습니다.
REST API 보안도 업계 모범 사례에서 시작됩니다. 암호 보안을 위해 해싱 알고리즘을 사용하고 보안 데이터 전송을 위해 HTTPS를 사용합니다. OAuth 2.0과 같은 인증 프레임워크는 타사 애플리케이션의 권한을 제한하는 데 도움이 될 수 있습니다.
API는 HTTP 헤더의 타임스탬프를 사용하여 특정 기간 후에 도착하는 모든 요청을 거부할 수도 있습니다. 매개 변수 유효성 검사 및 JSON 웹 토큰은 권한이 있는 클라이언트만 API에 액세스할 수 있도록 보장하는 다른 방법입니다.
IBM API Connect의 보안 API 관리를 통해 여러 클라우드에서 API 라이프사이클을 관리하고 소셜화를 강화하며 전체 비즈니스 에코시스템에서 수익화 노력을 최적화합니다.
통합 솔루션을 통한 비즈니스 잠재력 연결, 자동화 및 활용
온프레미스, 프라이빗 클라우드 또는 퍼블릭 클라우드 환경 내에서 호스팅되는 다양한 애플리케이션, 데이터, 비즈니스 프로세스 및 서비스를 연결하세요.
API(애플리케이션 프로그래밍 인터페이스)를 통해 애플리케이션이 데이터와 기능을 간단하고 안전하게 교환할 수 있도록 함으로써 소프트웨어 개발 및 혁신을 간소화하는 방법을 알아보세요.
API 관리에 대해 알아보고 통합 API 관리 플랫폼이 비즈니스 성장에 어떤 도움을 주는지 알아보세요.
Gartner가 IBM을 선도 기업으로 선정한 이유에 대한 자세한 내용은 2023년 Gartner Critical Capabilities for Full Lifecycle API Management 보고서를 참조하세요.