API란 무엇인가 - API에 대해 알아보기

애플리케이션 프로그래밍 인터페이스(API)는 서로 다른 소프트웨어 구성 요소들이 서로 통신할 수 있도록 하는 표준과 프로토콜을 정의합니다. 이를 통해 애플리케이션은 독립적인 시스템으로부터 데이터와 작업을 요청할 수 있습니다.

API는 어디에나 존재합니다. 기기 및 소프트웨어와의 거의 모든 상호작용을 뒷받침합니다. 예를 들어, 휴대폰의 앱은 서버에서 데이터를 가져오기 위해 API를 사용한 후, iOS와 Android가 제공하는 별도의 API에 의존하여 데이터를 화면에 표시하거나, 푸시 알림을 통해 사용자에게 전송하거나, 연락처와 공유합니다.

API의 형태가 매우 다양하기 때문에, 이들이 어떻게 조화를 이루는지 이해하기 어려울 수 있습니다. 어떤 유형의 API가 존재할까요? 무엇이 API로 인정받을 수 있을까요? 자신만의 API는 어떻게 만들 수 있을까요? 이 포괄적인 가이드에서 여러분은 이러한 모든 질문에 대한 답을 배우게 될 것입니다.

API란 무엇인가?

애플리케이션 프로그래밍 인터페이스 (Application Programming Interface )라는 용어는 다소 난해해 보일 수 있지만, 특정 개념을 가리킵니다. 가장 간단히 말해 API는 개발자가 애플리케이션과 연동되는 코드를 프로그래밍할 수 있게 해주는 것입니다. 이는 상호 운용성을 용이하게 하는 인터페이스, 즉 두 개 이상의 시스템이 준수해야 하는 규칙, 절차, 기대 사항 및 표준을 정의합니다.

예시를 통해 이 개념을 살펴보겠습니다: 신규 사용자 등록을 위한 API를 제공하는 신원 플랫폼을 생각해 보세요. 외부 애플리케이션은 이 API를 사용해 필요에 따라 사용자를 생성할 수 있지만, 이를 위해서는 데이터가 플랫폼이 기대하는 형식이어야 합니다.

API는 다음과 같은 요구사항을 정의합니다: 클라이언트 애플리케이션이 example.com/users로 HTTP POST 요청을 보내야 하며, Name, Email, Password 데이터 필드가 포함되어야 하며, 응답으로 새 사용자의 ID를 포함한 JSON 본문이 반환된다는 점 등입니다. 개발자는 이 정보를 바탕으로 API를 활용해 새 사용자를 성공적으로 등록할 수 있습니다.

본질적으로 API는 개발자가 호출할 수 있는 플랫폼 코드와 사용 방법을 설명하는 문서의 조합입니다.

API가 중요한 이유는 무엇인가요?

API는 시스템 간 데이터 흐름을 가능하게 합니다. 이를 통해 소프트웨어는 다른 애플리케이션을 기반으로 구축되어 더 강력한 솔루션을 창출할 수 있습니다.

또한 자동화에 필수적입니다. 서로 다른 API의 기능을 하나의 애플리케이션에 통합함으로써, 작업과 이벤트 발생 시 시스템 간 데이터 이동이 가능합니다. 개발자는 수작업 프로그래밍이 필요했던 복잡한 프로세스를 몇 줄의 코드로 구현할 수 있습니다.

예를 들어 웹 스크래핑은 복잡한 작업입니다. 효과적인 웹 스크래퍼를 구현하려면 웹 브라우저 인스턴스 제어, 지리적 위치 프록시 설정, CAPTCHA 우회 등을 위한 정교한 로직을 개발해야 합니다. API를 선택하면 몇 번의 네트워크 요청만으로 이 모든 기능을 이용할 수 있습니다. 이후 다른 API를 활용해 스크래핑된 데이터를 조작하고 분석한 결과를 채팅 플랫폼의 팀원에게 전송할 수 있습니다.

또한 API는 비즈니스 자산입니다. 다른 도구와의 손쉬운 연동을 지원하면 플랫폼의 고객 매력이 높아집니다. 외부 개발자들은 각 구성 요소 이상의 가치를 지닌 자체 솔루션을 자유롭게 구축할 수 있습니다.

API는 오늘날 초연결 프로세스에 매우 중요합니다. 당연시되는 많은 기술들은 복잡한 API 네트워크에 의해 구동됩니다. 예를 들어, 온라인 쇼핑에는 일반적으로 여러 독립 공급업체가 호스팅하는 결제 수집, 배송 요청, 이메일 전송 API가 포함됩니다.

API의 유형

개별 API는 소속된 서비스에 맞춰 서로 다른 기능을 제공합니다. 예를 들어, 신원 관리 솔루션은 검색 엔진 스크래핑 제공업체와 매우 다른 API 기능을 제공합니다.

그러나 표면상 관련 없어 보이는 API들의 기술적 특성은 종종 매우 유사합니다. 대부분의 인기 API는 소프트웨어 산업이 시스템 통합에 효과적이라고 입증한 기법을 나타내는 몇 가지 표준을 사용합니다.

다양한 API 유형을 살펴보겠습니다:

#REST

표현적 상태 이전(REST)은 2000년 Roy Fielding에 의해 처음 이론화되었으며, 현재 대부분의 웹 서비스에서 사용됩니다.

REST는 시스템의 데이터를 HTTP URL에 매핑된 상태 비저장(stateless) 리소스로 표현합니다. HTTP 메서드(GET, POST, PUT, DELETE)를 사용하여 리소스를 검색하고 해당 리소스에 대한 작업을 수행합니다.

예를 들어, example.com/users/100에 대한 GET 요청은 ID 100의 사용자에 대한 다음 정보를 반환해야 합니다:

  n{n    u0022Idu0022: 100,n    u0022Nameu0022: u0022Example Useru0022,n    u0022Emailu0022: [email protected]}

동일한 URL에 DELETE 요청을 수행하면 서비스는 해당 객체를 삭제해야 합니다.

REST는 구현이 쉽고 HTTP를 기반으로 하며, 실제 애플리케이션이 데이터를 처리하는 방식을 효과적으로 모델링하기 때문에 널리 사용됩니다. 많은 시스템과의 상호작용은 동사(DELETE)와 명사(user)의 조합으로 이루어지며, 이러한 아키텍처는 REST를 통해 직접 표현될 수 있습니다.

#SOAP

REST와 달리, 단순 객체 접근 프로토콜(SOAP) 은 데이터 공유를 위한 공식 사양입니다. 모든 SOAP 교환은 XML 데이터 형식을 사용하는 반면, REST API는 JSON, XML, CSV 또는 플랫폼별 대안을 제공할 수 있습니다. 간단한 SOAP API 호출은 다음과 같은 응답을 생성할 수 있습니다:

  xmlnu003c?xml version=u00221.0u0022 ?u003enu003csoap:Envelopen   t xmlns:soap=u0022https://www.w3.org/2003/05/soap-envelope/u0022n   t soap:encodingStyle=u0022https://www.w3.org/2003/05/soap-encodingu0022u003en   t u003csoap:Bodyu003en   tt u003cm:GetUserResponseu003en   ttt u003cm:Idu003e100u003c/m:Idu003en   ttt u003cm:Nameu003eExample Useru003c/m:Nameu003en   ttt u003cm:[email protected]/m:Emailu003en   tt u003c/m:GetUserResponseu003en   t u003c/soap:Bodyu003enu003c/soap:Envelopeu003ennxmlnu003c?xml version=u00221.0u0022 ?u003enu003csoap:Envelopen   t xmlns:soap=u0022https://www.w3.org/2003/05/soap-envelope/u0022n   t soap:encodingStyle=u0022https://www.w3.org/2003/05/soap-encodingu0022u003en   t u003csoap:Bodyu003en   tt u003cm:GetUserResponseu003en   ttt u003cm:Idu003e100u003c/m:Idu003en   ttt u003cm:Nameu003eExample Useru003c/m:Nameu003en   ttt u003cm:[email protected]/m:Emailu003en   tt u003c/m:GetUserResponseu003en   t u003c/soap:Bodyu003enu003c/soap:Envelopeu003e

XML 사용과 프로토콜 특정 속성 포함으로 인해 SOAP는 일반적인 REST API보다 더 장황합니다. 그러나 SOAP의 표준화 이점은 많은 대기업과 상용 시스템에서 선호하는 이유입니다. API에서 사용 가능한 작업은 XML 스키마로 명시적으로 정의됩니다. 이는 각 요청과 응답의 구조 및 데이터 유형을 설명하여 클라이언트-서버 불일치 발생 위험을 줄입니다.

#GraphQL

GraphQL은 조작 가능한 API 구축을 위한 비교적 새로운 기술입니다. 2012년 Facebook에서 개발되어 2015년 공개되었습니다.

GraphQL은 REST 및 SOAP API의 여러 문제점을 해결하기 위해 설계되었습니다. 클라이언트가 API에서 데이터를 추출하는 데 사용할 수 있는 표현력 있는 언어를 제공함으로써 복잡한 쿼리를 단순화합니다. GraphQL을 사용하면 항상 전체 객체를 제공하는 대신 필요한 특정 데이터 필드만 가져올 수 있습니다. 이는 중복 데이터의 낭비적인 전송을 방지합니다.

사용자의 이메일 주소를 가져오는 간단한 GraphQL 쿼리는 다음과 같습니다:

  {n    user {n   t Emailn    }n}{n    user {n   t Emailn    }n}

이 쿼리는 다음과 같은 응답을 생성합니다:

  jsonn{n    u0022useru0022: {n   t u0022Emailu0022: [email protected]    }n}jsonn{n    u0022useru0022: {n   t u0022Emailu0022: [email protected]    }n}

GraphQL은 오늘날의 고도로 연결된 애플리케이션에 더 적합한 다목적 옵션이기 때문에 인기를 얻고 있습니다. 이러한 애플리케이션에서는 여러 서로 다른 구성 요소가 독립적으로 소량의 데이터를 가져옵니다. 그러나 GraphQL 구현은 상대적으로 복잡할 수 있으며 언어별 프로그래밍 도구를 사용하여 처리하는 것이 가장 좋습니다.

#RPC

원격 프로시저 호출(RPC)은 단순한 형태의 API입니다. 이 기술은 원격 함수를 마치 로컬에서 사용 가능한 것처럼 호출하는 것을 의미합니다. 기본적인 네트워크 요청으로 API 서버가 작업을 수행하고 결과를 제공합니다. 클라이언트는 네트워크 통신 세부 사항에 노출되지 않습니다.

RPC API는 함수형 프로그래밍 인터페이스와 유사하게 보입니다. 호출하는 URL에는 동사와 명사가 모두 포함됩니다(예: example.com/deleteUser?User=100). 이는 특정 명사에 동사를 적용하는 REST(DELETE example.com/users/100)와 대비됩니다. RPC는 코드에 더 직접적으로 매핑되는 반면, REST는 데이터 구조를 모델링하려고 시도합니다.

RPC는 클라이언트와 서버 모두 사용하기 쉽습니다. 다양한 요청 매개변수를 받아들이고 응답으로 데이터를 전송하는 URL 모음입니다. 그러나 표준화가 되어 있지 않아 개발자가 탐색하기 어려운 경향이 있습니다. 반면 대부분의 REST API 엔드포인트는 서비스 리소스 이름을 알면 예측 가능하며, RPC에 사용되는 URL은 플랫폼마다 고유합니다.

gRPC와 같은 현대적 프로젝트를 통해 RPC가 개선되고 있습니다. 이는 여러 프로그래밍 언어로 작동하는 프레임워크로, Google의 고성능 구조화된 데이터 직렬화 방식인 프로토콜 버퍼를 사용하여 클라이언트와 통신하는 RPC API 서비스를 신속하게 정의하는 데 활용될 수 있습니다.

시스템 API

REST, SOAP, GraphQL, RPC API는 시스템 간 네트워크 통신 맥락에서 사용됩니다. 애플리케이션이 기기 기능에 접근할 수 있게 하는 시스템 인터페이스처럼, 다른 종류의 통합을 위한 API도 존재합니다.

이러한 API는 Windows, Android, iOS와 같은 운영 체제에서 제공됩니다. 개발자가 코드에서 호출할 수 있는 프로그래밍 프레임워크 및 SDK를 통해 노출됩니다. 시스템 API를 사용하면 프로그래머가 저수준 코드를 작성할 필요 없이 알림, 런처 아이콘, 미디어 재생, 기기 센서 접근과 같은 기능에 편리하게 접근할 수 있습니다.

프로그래밍 언어 API

마찬가지로 프로그래밍 언어와 종속성에도 고유한 API가 존재합니다. 언어 표준 라이브러리에 포함된 모듈은 API를 나타냅니다. 프로젝트에 설치하는 타사 패키지도 API이며, 작성한 컴포넌트는 정의된 인터페이스를 통해 서로 연결됩니다.

API는 언제든 변경될 수 있는 시스템 내부 작동 방식과 통합자가 의존하는 안정적인 외부 인터페이스 사이의 경계입니다. 코드베이스에서 public으로 표시된 메서드와 함수는 다른 코드가 활용할 수 있는 API를 생성합니다.

동기식 및 비동기식 API

API는 동기식 또는 비동기식으로 구현될 수 있습니다. 동기식 API는 요청된 작업의 결과를 즉시 반환하는 반면, 비동기식 API는 데이터 교환이 완료된 후에도 실행을 계속할 수 있습니다.

데이터 수집 API의 경우, 현재 수집된 데이터를 요청하는 것은 동기식 작업으로 항상 지금까지 검색된 데이터를 반환합니다. 새로운 데이터 수집 스크래핑을 요청하는 것은 비동기식일 수 있는데, 이 프로세스가 완료되는 데 오랜 시간이 걸릴 가능성이 높기 때문입니다. API가 수집이 예약되었다는 사실을 클라이언트에게 알린 후 즉시 통신을 종료하는 것이 더 효율적입니다.

자세히 살펴보기: API 작동 방식

일반적인 API 유형마다 고유한 문법이 있습니다. 예를 들어 REST는 객체와 동사를 기반으로 작동하는 반면, GraphQL은 서버 중심이 아닌 클라이언트 중심의 보다 유연한 솔루션을 제공합니다. 이 두 가지 옵션을 자세히 살펴보겠습니다:

# REST

REST는 HTTP 메서드 동사를 사용하여 리소스에 대한 작업을 수행합니다. 가장 일반적인 메서드는 GET, POST, PUT, DELETE입니다:

– GET /users/100: 사용자 ID 100을 반환합니다.

– POST /users: 새 사용자를 생성합니다.

– PUT /users/100: ID로 사용자를 업데이트합니다.

– DELETE /users/100은 ID로 사용자를 삭제합니다.

이는 기본 REST 구문을 보여줍니다. URL은 상호작용 대상 객체의 ID와 해당 객체가 속한 복수 명사를 제공합니다. 클라이언트가 사용하는 HTTP 메서드가 수행될 작업을 결정합니다.

작업 완료에 추가 데이터가 필요한 경우, 해당 데이터는 HTTP 요청의 페이로드로 제공됩니다. 예를 들어, POST /users로 사용자를 생성할 때 본문에 할당할 사용자 이름과 비밀번호가 포함됩니다.

API는 각 요청에 대해 결과를 설명하는 HTTP 상태 코드로 응답합니다. 예를 들어, GET /users/100에 대한 404 Not Found 응답은 사용자 ID 100이 존재하지 않음을 나타내며 , DELETE /users/100에 대한 202 Accepted는 사용자가 성공적으로 삭제되었음을 의미합니다.

#GraphQL

반면 GraphQL은 API에 대한 다른 접근 방식입니다. [“API를 위한 쿼리 언어”](https://graphql.org)로 소개되며, 더 진보된 기능을 지원함을 암시합니다. REST가 불필요한 객체 속성을 포함하여 대역폭을 낭비하는 경우가 많은 반면, GraphQL은 정확히 원하는 데이터만 요청할 수 있게 합니다.

GraphQL을 사용하는 API는 클라이언트가 호출할 수 있는 엔드포인트를 정의하는 서비스 형태로 작성됩니다. 서비스는 엔티티에 대한 타입화된 스키마입니다. 스키마의 각 필드에는 특정 데이터 타입이 할당됩니다:

  type Team {n    id: IDn    name: Stringn}nntype User {n    id: IDn    name: Stringn    email: Stringn    team: Teamn}ntype Team {n    id: IDn    name: Stringn}nntype User {n    id: IDn    name: Stringn    email: Stringn    team: Teamn}

스키마에서 쿼리를 사용하여 데이터를 가져올 수 있습니다:

  {n    user(id: 100) {n   t email,n   t team {n   tt namen   t }n    }n}n{n    user(id: 100) {n   t email,n   t team {n   tt namen   t }n    }n}

이 예시 쿼리는 다음과 같은 데이터를 반환할 수 있습니다:

  {n    u0022emailu0022: [email protected],n    u0022teamu0022: u0022Example Teamu0022n}n{n    u0022emailu0022: [email protected],n    u0022teamu0022: u0022Example Teamu0022n}

쿼리의 필드는 리졸버(resolver)에 의해 지원됩니다. 쿼리가 실행되면 리졸버는 각 필드에 대한 값을 생성하는 역할을 합니다. 이전 예시에서 팀 리졸버는 요청된 사용자에게 할당된 팀 객체 전체를 반환하는 대신 name 속성만 추출합니다.

GraphQL은 뮤테이션을 통해 데이터를 업데이트하는 일관된 방법도 제공합니다. 뮤테이션은 쿼리와 유사하지만 서버 상태를 변경합니다. 뮤테이션은 서비스의 각 필드에 대한 함수를 정의하여 구현됩니다. 이 함수는 필드에 새 값을 저장하는 역할을 합니다.

GraphQL API는 일반적으로 프로젝트에 GraphQL 클라이언트 라이브러리를 추가하여 생성됩니다. 이러한 도구를 사용하면 기존 ORM 모델 및 기타 코드에서 GraphQL 스키마를 편리하게 생성할 수 있습니다.

API 통합 방법

API 통합은 소프트웨어 시스템 내에서 API를 채택하는 과정을 설명합니다. API가 즉시 사용 가능한 기능을 제공하더라도, 프로젝트 내에서 이를 사용하려면 일부 사용자 정의 코드를 작성해야 합니다.

일반적인 API 통합은 다음 단계를 포함합니다:

1. 사용 가능한 옵션 평가: 먼저 사용 사례를 해결하는 다양한 API를 평가하고 제품에 가장 적합한 API를 식별해야 합니다. 여기에는 문서 품질, API를 사용하는 활발한 커뮤니티의 존재 여부, 유지보수 담당자가 지원 요청, 보안 문제 및 버그 수정 보고에 얼마나 신속하게 응답하는지 등을 살펴보는 것이 포함됩니다.

2. 서비스 가입 및 API 키 요청: 일부 API는 공개적으로 노출되어 인증이 필요 없지만, 대부분의 API는 기본 사용량 한도를 초과하면 가입 후 API 키를 획득해야 합니다. API 키는 민감한 값으로 취급하여 안전하게 저장해야 합니다—프로젝트 코드에 하드코딩하지 마십시오. 이 키는 서비스에 대한 인증을 수행하고, 속도 제한 및 사용량 추적을 위해 애플리케이션을 식별합니다.

3. 사용 중인 프로그래밍 언어용 API 클라이언트 라이브러리 찾기: 프로그래밍 언어의 HTTP 라이브러리를 사용해 직접 네트워크 요청을 보내 API를 통합할 수 있습니다. 그러나 많은 API 공급업체는 API를 감싸 더 편리한 프로그래밍 환경을 제공하는 클라이언트 라이브러리 및 SDK도 제공합니다. 사용 가능한 클라이언트 라이브러리를 선택하면 구현을 더욱 단순화하고 기본 API의 호환성 깨짐 변경으로부터 보호받을 수 있습니다.

4. 코드 작성: 라이브러리를 확인한 후에는 API와 상호작용하는 코드를 작성할 차례입니다. 사용 중인 라이브러리를 획득한 API 키로 구성해야 합니다. 또한 데이터 센터 지역이나 선호하는 응답 형식 등 서비스가 요구하는 구성 매개변수를 설정해야 할 수도 있습니다.

5. API 통합 테스트: 마지막으로 통합이 예상대로 작동하는지 테스트하세요. 테스트에는 API가 사용 불가능할 때의 처리 방식 등 오류 처리 루틴 점검이 포함되어야 합니다. 이는 서비스 중단 시 애플리케이션의 복원력을 보장하는 데 도움이 됩니다.

API 통합 시 보안 영향도 고려해야 합니다. 타사 API가 핵심 개발 작업을 단순화할 수 있지만, 사용자 데이터를 외부 서비스로 전송할 때는 신중해야 합니다. 해당 플랫폼이 자체 보안 기준을 충족할 수 있을까요? API 기능을 쉽게 재현할 수 있다면 애플리케이션 내에서 자체 구현을 구축하는 것이 더 안전할 수 있습니다.

실제 API 예시

API 사용 준비가 되셨나요? 웹 API를 빠르게 실험하려면 curl이나 wget과 같이 이미 컴퓨터에 설치된 HTTP 도구를 사용할 수 있습니다. 그래픽 인터페이스를 선호한다면 Postman이 좋은 대안입니다.

Faker로 가짜 데이터 생성하기

Faker API 프로젝트는 다양한 주제에 대해 무작위로 생성된 데이터를 반환하는 인기 있는 API 모음입니다. Faker API는 실제 백엔드가 준비되기 전에 인터페이스에 데이터를 채우기 위해 제품 개발 과정에서 자주 사용됩니다.

Faker API는 REST 원칙을 사용하며, URL 끝에 오는 명사가 생성할 데이터의 유형을 정의합니다:

  $ curl https://fakerapi.it/api/v1/books?_quantity=1n{ntu0022statusu0022: u0022OKu0022,ntu0022codeu0022: 200,ntu0022totalu0022: 1,ntu0022datau0022: [n    t{n        tu0022idu0022: 1,n        tu0022titleu0022: u0022Duck and a pair of.u0022,n        tu0022authoru0022: u0022Jessyca McKenzieu0022,n        tu0022genreu0022: u0022Situ0022,n        tu0022descriptionu0022: u0022ALL RETURNED FROM HIM TO YOU,u0022' said Alice. 'I wonder how many miles I've fallen by this time, as it can be,' said the Cat. 'u002du002dso long as I usedu002du002dand I don't take this child away with me,' thought.u0022,n        tu0022isbnu0022: u00229796054956226u0022,n        tu0022imageu0022: u0022http://placeimg.com/480/640/anyu0022,n        tu0022publishedu0022: u00222010-09-14u0022,n        tu0022publisheru0022: u0022Quod Enimu0022n    t}nt]n}n$ curl https://fakerapi.it/api/v1/books?_quantity=1n{ntu0022statusu0022: u0022OKu0022,ntu0022codeu0022: 200,ntu0022totalu0022: 1,ntu0022datau0022: [n    t{n        tu0022idu0022: 1,n        tu0022titleu0022: u0022Duck and a pair of.u0022,n        tu0022authoru0022: u0022Jessyca McKenzieu0022,n        tu0022genreu0022: u0022Situ0022,n        tu0022descriptionu0022: u0022ALL RETURNED FROM HIM TO YOU,u0022' said Alice. 'I wonder how many miles I've fallen by this time, as it can be,' said the Cat. 'u002du002dso long as I usedu002du002dand I don't take this child away with me,' thought.u0022,n        tu0022isbnu0022: u00229796054956226u0022,n        tu0022imageu0022: u0022http://placeimg.com/480/640/anyu0022,n        tu0022publishedu0022: u00222010-09-14u0022,n        tu0022publisheru0022: u0022Quod Enimu0022n    t}nt]n}

Bright Data를 이용한 검색 엔진 목록 스크래핑

Bright Data는 포괄적인 SERP API 및 프록시 API 제품군을 제공하는 상용 플랫폼으로, 등록이 필요합니다:

Screenshot of the Bright Data SERP API landing page

사용을 시작하려면 무료 체험판에 가입한 후, 문서를 따라 SERP API를 계정에 추가하세요. 그런 다음 API의 고급 옵션에서 비동기 모드를 활성화해야 합니다:

API 활성화 후 검색 엔진 결과를 수집하기 위해 POST 요청을 제출할 수 있습니다:

  $ curl -i u0022https://brightdata.com/api/serp/req?customer={CUSTOMER_ID}u0026zone={CUSTOMER_ZONE}u0022 n    -H u0022Content-Type: application/jsonu0022 n    -H u0022Authorization: Bearer {API_TOKEN}u0022 n    -d '{u0022countryu0022:u0022usu0022,u0022queryu0022:{u0022qu0022:u0022apisu0022}}'n...nx-response-id: s3wt2t...

계정 설정에서 API 토큰을 생성한 후, 명령어 내 `{API_TOKEN}` 대신 해당 토큰을 대체하여 입력하세요:

다른 자리 표시자 값( {CUSTOMER_ID}, {CUSTOMER_ZONE})은 SERP API 플레이그라운드에서 확인하실 수 있습니다.

이 예시 쿼리는 API를 사용하여 미국 Google에서 'apis'에 대한 검색을 예약합니다. 명령어 출력에 표시된 x-response-id 응답 헤더 값을 복사하세요. 이 값을 사용하여 SERP 결과가 생성된 후 이를 가져올 수 있습니다. 1분 정도 기다린 후 다음 요청을 실행하세요:

  $ curl u0022https://brightdata.com/api/serp/get_result?customer={CUSTOMER_ID}u0026zone={CUSTOMER_ZONE}u0026output=jsonu0026response_id={RESPONSE_ID}u0022$ curl u0022https://brightdata.com/api/serp/get_result?customer={CUSTOMER_ID}u0026zone={CUSTOMER_ZONE}u0026output=jsonu0026response_id={RESPONSE_ID}u0022

RESPONSE_ID를 이전에 복사한 값으로 대체하세요. 검색으로 생성된 데이터가 콘솔에 표시됩니다.

이러한 엔드포인트는 RPC API의 예시입니다. API가 RESTful인 경우 URL은 다음과 같은 형식을 가집니다:

POST /api/serp/request 및 GET /api/serp/results/{RESPONSE_ID}.

요약

API는 서로 다른 소프트웨어 구성 요소를 안정적으로 연결하는 데 사용할 수 있는 명확하게 정의된 인터페이스입니다. 그러나 API를 구성하는 요소는 형태, 변형, 사용 사례가 너무 다양하기 때문에 혼란스러울 수 있습니다.

일반적으로 API는 코드가 다른 코드가 구현한 기능에 접근하기 위해 사용할 수 있고 사용해야 하는 메커니즘입니다. API는 원격 시스템 개발자가 지원하며 사용 방법에 대한 지침과 함께 문서화됩니다. 이는 서비스와 API를 사용하는 클라이언트 애플리케이션 간에 계약을 생성합니다. 클라이언트가 예상된 형식으로 데이터를 전송하면 예측 가능한 구조의 응답을 받을 수 있습니다.

API는 시스템 내 특수 기능 구현을 단순화합니다. 해당 분야 전문가들이 어려운 작업을 대신 수행하도록 한 후, 그들의 플랫폼을 여러분의 코드에 연결할 수 있습니다. 웹 스크래핑 작업을 수행하기 위해 Bright Data의 SERP API 및 프록시 API 제품군을 사용해 보세요.

SERP 및 프록시 API 이용하기

문의하기 무료 체험 시작하기