API의 구성 요소는 무엇입니까?

API는 소프트웨어 구성 요소가 데이터 통신 및 전송을 가능하게 하는 코드 기반 지침 세트이며 모든 최신 응용 프로그램의 빌딩 블록입니다. 그러나 API 자체의 빌딩 블록은 무엇입니까? 이 기사에서는 끝에서 끝까지 요청을 따라 REST API의 다양한 구성 요소를 검토합니다.

API 클라이언트

API 요청은 다양한 방식으로 트리거될 수 있습니다. 예를 들어 사용자는 검색어를 입력하거나 버튼을 클릭하거나 웹 또는 모바일 애플리케이션에서 목록을 스크롤하여 API 요청을 시작할 수 있습니다. API 요청은 다른 애플리케이션이나 서비스의 알림과 같은 외부 이벤트에 대한 응답으로 발행될 수도 있습니다. API 요청이 트리거되는 방식에 관계없이 API 클라이언트는 API 서버를 조립하고 전달하는 일을 담당합니다.

"API 클라이언트"라는 문구는 문맥에 따라 다른 것을 의미할 수 있다는 점에 유의하는 것이 중요합니다. 첫째, 수동으로 API 요청을 보내는 복잡성을 추상화하여 API를 더 쉽게 탐색, 테스트 및 디버그할 수 있는 개발 도구를 의미할 수 있습니다. 더 큰 애플리케이션의 컨텍스트에서 API 요청을 시작하기 위해 언어별 라이브러리 및 SDK를 사용하는 서비스를 나타낼 수도 있습니다. 두 유형의 API 클라이언트 모두 API에서 반환된 데이터를 처리하고 사용자에게 제공하는 역할을 담당하지만, 후자 유형의 클라이언트는 애플리케이션의 논리적 흐름에서 반환된 데이터를 사용할 수도 있습니다.

API 요청

API 클라이언트가 사용자 작업이나 외부 이벤트에 대한 응답으로 API 요청을 보내는 역할을 한다고 언급했지만 API 요청이란 정확히 무엇입니까? API 요청은 API 유형에 따라 다르게 보이고 작동합니다. 즉, REST API에 대한 API 요청은 다음 구성 요소로 구성됩니다.

• 끝점: 모든 API 요청은 특정 리소스에 대한 액세스를 제공하는 전용 URL인 API 엔드포인트로 전달됩니다. 예를 들어 전자상거래 앱의 /products 엔드포인트에는 제품과 관련된 모든 요청을 처리하기 위한 논리가 포함됩니다. 따라서 요청은 API 서버가 진행 방법을 알 수 있도록 엔드포인트를 지정해야 합니다. 곧 API 서버에 대해 자세히 설명하겠습니다.
• 방법: 모든 API 요청에는 클라이언트가 지정된 리소스에서 수행하려는 작업을 정의하는 메서드가 포함되어야 합니다. REST API는 GET, POST, PUT, PATCH 및 DELETE와 같은 표준 HTTP 메서드를 통해 액세스할 수 있으며 데이터 검색, 생성, 업데이트 또는 삭제와 같은 일반적인 작업을 용이하게 합니다. /products 엔드포인트에 대한 GET 요청은 데이터베이스의 모든 제품을 반환하도록 API 서버에 알립니다.
• 매개변수: 매개변수는 API가 처리할 특정 지침을 제공하기 위해 API 엔드포인트에 전달되는 변수입니다. 이러한 매개변수는 URL, 쿼리 문자열 또는 요청 본문의 일부로 API 요청에 포함될 수 있습니다. 예를 들어 전자상거래 API의 /products 엔드포인트는 특정 색상의 제품에 액세스하고 반환하는 데 사용할 "색상" 매개변수를 수락할 수 있습니다.
• 요청 헤더: API 요청 헤더는 요청에 대한 추가 정보를 제공하는 키-값 쌍입니다. 예를 들어 Content-Type 헤더는 요청 본문의 데이터 형식을 지정하고 Authorization 헤더는 API 키 또는 OAuth 토큰과 같은 인증 자격 증명을 제공하여 요청자를 인증합니다.
• 요청 본문: 요청 본문에는 리소스를 생성, 업데이트 또는 삭제하는 데 필요한 실제 데이터가 포함됩니다. 예를 들어 전자 상거래 상점의 관리자가 새 제품을 만들어야 하는 경우 요청 본문에 제품 이름, 브랜드 및 가격이 포함될 수 있습니다. API 사양은 요청에 필요한 데이터 형식(예: JSON 또는 XML)을 지정합니다.

API 서버

API 클라이언트가 요청을 수집하면 처리를 위해 API 서버의 적절한 끝점으로 보냅니다. API 서버는 인증 처리, 입력 데이터 유효성 검사, 데이터베이스에서 데이터 검색 또는 조작, 클라이언트에 적절한 응답 반환을 담당합니다.

데이터베이스 자체는 API 구성 요소가 아니지만 데이터베이스 없이는 API가 작동할 수 없다는 점에 유의해야 합니다. API 서버가 요청에 따라 애플리케이션 데이터를 검색하고 조작하는 반면, 데이터베이스는 효율적인 검색 및 조작을 용이하게 하는 방식으로 이 데이터를 저장하고 구성합니다. 따라서 API 서버는 API 클라이언트와 데이터베이스 간의 중개자 역할을 합니다.

API 응답

위에서 API 서버가 요청을 처리한 후 클라이언트에 응답을 보내는 역할을 한다고 언급했습니다. API 응답의 내용은 요청 유형과 API 설계에 따라 크게 다를 수 있지만 일반적으로 다음 구성 요소를 포함합니다.

• 상태 코드: API 상태 코드는 클라이언트 요청의 상태를 나타내기 위해 API에서 반환하는 HTTP 상태 코드입니다. 이러한 코드는 클라이언트에게 요청 결과에 대한 정보를 제공하고 클라이언트가 진행 방법을 이해하도록 돕는 데 사용됩니다. 가장 일반적인 상태 코드 중 일부는 서버가 요청된 데이터를 성공적으로 반환했음을 나타내는 200 OK, 서버가 새 리소스를 성공적으로 생성했음을 나타내는 201 Created 및 서버가 요청된 데이터를 찾을 수 없음을 나타내는 404 Not Found를 포함합니다. 자원.
• 응답 헤더: 응답 헤더는 서버 응답에 대한 추가 정보를 제공하는 데 사용된다는 점을 제외하면 요청 헤더와 매우 유사합니다. 예를 들어 Cache-Control 헤더는 데이터를 캐시에 저장할 수 있는 기간에 대한 지침을 제공하고 Set-Cookie 헤더는 세션 관리 또는 인증에 사용할 수 있는 쿠키를 브라우저에 설정합니다.
• 응답 본문: 응답 본문에는 클라이언트 요청에 대한 응답으로 API 서버에서 반환하는 데이터 또는 콘텐츠가 포함됩니다. 응답 본문은 매우 다양하지만 일반적으로 요청된 리소스, 메타데이터 및 요청이 실패한 경우 무엇이 잘못되었는지에 대한 오류 메시지를 나타내는 구조화된 데이터 개체를 포함합니다. 예를 들어 특정 제품에 대한 성공적인 GET 요청에는 해당 제품의 JSON 표현과 타임스탬프 및 데이터 소스가 포함될 수 있습니다.

REST는 가장 일반적인 API 아키텍처이지만 GraphQL 및 gRPC와 같은 다른 유형의 API에는 다른 구성 요소가 있습니다. 그럼에도 불구하고 이 목록에는 모든 RESTful API에 대한 요청 실행과 관련된 핵심 구성 요소가 포함되어 있습니다.

오늘날 수만 명의 개발자가 Apitgit 플랫폼을 사용합니다. Apitgit은 API 수명 주기의 각 단계를 단순화하고 협업을 간소화하여 더 나은 API를 더 빠르게 만들 수 있습니다.