이 섹션에서는 API가 무엇이고 그것이 버블앱에서 어떻게 사용할 수 있는지 알아볼 것입니다.
이 챕터는 RESTful API의 일반적인 설명이 포함됩니다.
: 세상에는 매우 많은 종류의 API가 있습니다.
그러나 그것들은 다음과 같이 비슷한 두 개의 패턴으로 이루어져 있습니다.
- CLIENT는 다른 시스템으로 요청(request)을 보냅니다.
- SERVER는 그것의 응답(response)을 다시 보냅니다.
(1) API에 대한 소개
: Bubble앱을 다른 애플리케이션이나 데이터 소스에 연결하려는 경우 API를 사용합니다.
API는 두 애플리케이션이 공통 언어를 사용하여 안전하게 연결을 설정하고 정보를 교환하고 워크플로를 트리거할 수 있도록 하는 일종의 원칙입니다.
- 이 기술은 수십 년 동안 사용되어 왔습니다.
- 컴퓨터 프로그램이 상업용으로 처음 개발되었던 1960년대와 1970년대로 거슬러 올라갑니다.
- 그 이후로 기술과 보안이 발전했지만 많은 기본 원칙이 여전히 적용되고 있습니다.
Bubble은 당신을 위해 많은 기술적인 것들을 처리하도록 설정되었습니다.
- 이렇게 하면 들어오고 나가는 API연결을 모두 안전하고 효율적으로 설정할 수 있습니다.
- 그래도 API Call의 다양한 설정과 값이 의미하는 바를 이해하기 위해 내부에서 어떤 일이 벌어지고 있는지 아는 것이 유용할 수 있습니다.
Bubble API 용어 정리(중급) : 버블 Data API, Workflow API, 백엔드 워크플로우 종류 > 바로가기
(2) API call의 예시
: 만약 특정위치의 일기예보를 표시하는 여행 계획 소프트웨어를 Bubble에 구축했다고 상상해 보십시오
- 날씨 데이터를 얻으려면 앱(클라이언트)이 날씨 서비스의 서버(서버)에 요청(call)을 보내야 합니다.
- 서버는 요청을 처리하고 날씨 데이터를 검색한 다음 앱이 이해할 수 있는 형식으로 앱에 다시 보냅니다.
- 이 데이터를 가져와 사용자에게 친숙한 방식으로 표시합니다.
- 전체 프로세스는 일반적으로 수백 밀리초 내에 완료됩니다.
API를 사용하면 특정 정보를 요청하거나 외부 애플리케이션의 매우 특정한 제약 내에서 명령을 실행할 수 있지만 애플리케이션이 실제로 작동하는 방식에 대한 접속은 허용하지 않습니다.
- 예를 들어 날씨 서비스에 연락해도 날씨 데이터가 어떻게 저장되고 처리되는지에 대해 알 수 없습니다.
- 정확한 요청에 대한 응답으로 짧은 텍스트 데이터만 제공됩니다.
- 즉, API는 외부 애플리케이션의 내부 작업을 공개하지 않고 통신 라인만을 제공합니다.
- 어떤 면에서 보면 레스토랑에서 음식을 주문하는 것과 같습니다. 메뉴는 정적인 옵션 세트를 제공하고 선택한 것은 무엇이든 눈에 띄지 않게 주방에서 준비됩니다. 당신은 주방에 접근할 수 없으며 요리사는 그들의 비밀 레시피를 비밀로 유지하게 됩니다.
Restful API 란? (중급) : 일반적인 Restful API에 대한 설명 > 바로가기
(3) 수신연결 & 발신연결 (Incoming & Outgoing connections)
두 시스템은 서로 통신할 수 있으므로 연결이 양방향으로 진행될 수 있습니다.
이는 Bubble 앱이 타사에 연결할 수 있고 타사가 당신의 Bubble 앱에 연결할 수 있음을 의미합니다.
이 두 가지 유형의 연결을 두 가지 범주로 분류합니다.
1. 수신연결 (Incoming connections)
: 수신연결은 다른 시스템이 연결을 시작할 수 있고 Bubble 응용 프로그램이 다음 작업을 수행할 수 있음을 의미합니다.
- 데이터를 다시 보내기
- 데이터베이스 변경(하나 이상의 레코드 생성, 수정 또는 삭제)
- 특정 API 워크플로 실행
앱 간에 데이터와 명령을 공유할 수 있게 되면 다양한 기술과 서비스를 창의적인 방식으로 함께 사용할 수 있는 가능성의 세계가 열립니다.
- 여러 면에서 API표준은 오늘날 우리가 알고 있는 웹의 큰 부분을 지원하고 있습니다.
- Data API 또는 Workflow API를 활성화하면, Bubble은 들어오는 수신연결(Incoming connections )을 수락할 준비가 되도록 앱을 자동으로 설정하여 안전하고 제어된 방식으로 애플리케이션의 데이터를 다른 시스템에 빠르고 쉽게 전달할 수 있습니다.
Bubble API 소개(중급) : 버블 Data API, 버블 Workflow API, 버블 Swagger 설정, FAQ > 바로가기
2. 발신연결 (Outgoing connections)
:발신 연결은 애플리케이션이 다음 작업을 위해 다른 시스템과의 연결을 시작함을 의미합니다.
- 해당 시스템에서 데이터 검색
- 해당 시스템으로 데이터 보내기
- 해당 시스템에서 제공하는 기능 또는 기능에 액세스
발신연결(Outgoing connections)을 사용하여 다음과 같은 작업을 수행할 수 있습니다.
- 날씨 보고서, 주가, 애니메이션 GIF 및 소셜 미디어 프로필과 같은 데이터 가져오기
- Google 캘린더에 캘린더 이벤트 추가, Freshbooks에서 인보이스 생성 또는 Hubspot CRM에 새 연락처 추가와 같은 데이터 전송
- 다른 시스템(예: Google, Facebook 및 LinkedIn)의 기존 계정을 사용하여 사용자 로그인
- SendGrid로 이메일 보내기, Stripe 또는 Paypal로 결제하기, Twilio로 SMS 보내기와 같은 워크플로 시작
API Connector (중급) : 버블 API 커넥터 설정 및 사용, HTTP method, endpoint > 바로가기
(4) 클라이언트, 서버와 자원 (Client, server and resource)
1. 클라이언트와 서버
API 연결이 설정될 때마다, 클라이언트와 서버라는 두 당사자가 설정됩니다. 클라이언트는 요청을 보내는 시스템이고 서버는 응답하는 시스템입니다.
1) 클라이언트: API 커넥터 또는 플러그인을 사용하여 타사에 연결하는 경우의 앱
2) 서버: 다른 시스템이 당신의 Bubble API에 연결되어 있는 경우, 당신의 앱
2. 자원 (Resource)
: 자원(Resource)은 API를 통해 액세스 할 수 있는 특정 데이터 또는 기능입니다.
- API는 여러 자원(Resource)을 노출하므로 클라이언트가 접속하려는 자원(Resource)을 지정해야 합니다.
- 예를 들어 타사 시스템의 사용자 리스트를 가져오거나 새 데이터베이스를 만들거나 워크플로를 시작하기 위해 Bubble 애플리케이션에 연결할 수 있습니다.
- 이들 각각은 이 클라이언트가 액세스 할 수 있는 리소스로 간주됩니다.
앱이 CRM과 같은 외부 시스템에 연결하여 연락처를 생성하고 캘린더 이벤트 목록을 가져오거나 고객 이메일을 보내는 경우 이러한 각 작업도 별도의 리소스가 됩니다.
- 자원(Resource)은 일반적으로 해당 자원(Resource)을 가리키고 있는 특정 URL을 통해 접속됩니다.
- Bubble은 두 가지 종류의 자원(Resource)를 제공하며 자원(Resource)이 앱의 API에 노출되도록 설정될 때마다 URL이 자동으로 생성됩니다.
1) Data API
- 다른 시스템이 레코드를 읽고, 만들고, 수정하고, 삭제할 수 있도록 데이터베이스의 데이터 유형을 노출할 수 있습니다. 노출된 각 데이터 유형과 해당 데이터 유형에 연결된 각 작업(생성, 편집 및 삭제)은 외부에서 액세스 할 수 있는 Data API로 수행됩니다.
2) Workflow API
- 다른 시스템에서 워크플로를 트리거할 수 있도록 워크플로를 노출할 수 있습니다. 여기서 설정하고 노출하는 각 워크플로는 Workflow API로 수행됩니다.
(5) 인증과 권한부여 (Authentication and authorization)
API보안을 논의할 때 유사하게 들리는 두 단어를 명확하게 구분해야 합니다.
1. 인증 (Authentication)
- 인증은 서버에 액세스 하려는 클라이언트의 ID를 확인하는 프로세스입니다.
- 비행기에 탑승하려는 승객에 비유할 수 있습니다. 승객은 일반적으로 여권의 형태로 자신의 신원을 확인하기 위해 유효한 자격 증명을 제시해야 하는 보안 검색대에 도달하게 됩니다.
→ 즉, 인증은 클라이언트가 누구인지 묻는 것입니다.
Authentication (중급) : API 인증 bearer token, 인증 없이 접속, 사용자 인증, 관리자 인증> 바로가기
2. 권한부여 (Authorization)
- 인증은 클라이언트가 누구인지 식별하고 권한부여는 클라이언트가 액세스 할 대상을 결정합니다.
- 권한부여는 인증 후에 발생하며 클라이언트가 특정 작업을 수행하거나 서버의 특정 리소스에 액세스 하는 데 필요한 권한이 있는지 확인하는 프로세스입니다.
- 공항의 예로 돌아가서 승객이 누구인지 파악한 후 비행기 탑승 및 VIP 라운지에 대한 액세스 권한이 있는지 여부를 결정할 수 있습니다.
→ 즉, 권한 부여는 클라이언트가 수행할 수 있는 작업을 묻는 것입니다. 타사 시스템이 앱에 연결을 시도할 때마다 이 두 가지 보안 프로세스를 사용하여 연결할 수 있는 사람과 액세스 할 수 있는 항목을 완벽하고 안전하게 제어할 수 있습니다.
(6) 웹훅 (Webhooks)
두 애플리케이션이 때때로 실시간으로 일종의 정보를 교환해야 합니다.
- 즉, 한 앱에서 특정 이벤트가 발생하면 다른 앱에 이벤트를 알려야 합니다.
이러한 종류의 호출을 웹훅(webhook)라고 합니다.
특정 이벤트가 발생할 때 만들어지는 특정 목적으로 생성된다는 점을 제외하고는 다른 API 호출과 기술적으로 다르지 않습니다.
*웹훅 예시
Stripe 같은 결제 게이트웨이는 결제 시도의 성공 여부를 앱에 알려줄 수 있습니다.
- 인벤토리(창고 재고) 플랫폼(예: Shopify의 인벤토리 모듈)은 항목의 인벤토리(재고)가 부족하거나 부족할 때 앱에 알려야 할 수 있습니다.
- CRM은 새 리드가 생성될 때마다 웹훅을 보낼 수 있습니다.
- Calendly와 같은 예약 플랫폼은 새 약속이 예약될 때마다 알림을 보낼 수 있습니다.
예제에서 볼 수 있듯이 웹훅는 시스템을 동기화 상태로 유지하는 시간에 민감한 API 호출로 간주될 수 있습니다.
- 다른 API 호출과 마찬가지로 보고하는 이벤트에 정보를 전달하는 매개변수를 포함할 수 있습니다. 예를 들어 Stripe의 결제 웹훅 호출에는 결제금액, 결제 ID 및 고객 ID와 같은 정보가 포함될 수 있습니다.
- 웹훅은 특정 이벤트의 결과로 만들어진 API 호출입니다. 예를 들어 Stripe는 결제가 성공했음을 확인하기 위해 웹후크를 앱에 보낼 수 있습니다.
- 또한 다른 워크플로와 마찬가지로 웹후크는 Data API에 연결하여 데이터베이스를 변경하거나 Workflow API에 연결하여 앱에서 워크플로를 트리거할 수 있습니다.
