이 섹션에서는 API와 관련된 Bubble 관련 용어를 다룹니다.
지금까지 API소개 시리즈에서 본 것처럼 API를 사용하여 작업하면 Bubble이 발명한 것이 아닌 포괄적으로 사용된 일반적인 API용어를 접하게 됩니다.
- 또한 Bubble은 API의 다양한 부분을 설명하기 위해 자체 용어를 도입했습니다.
- 새로운 사용자에게는 처음에는 혼란스럽고 때로는 중복되는 것처럼 보일 수 있습니다.
- 그래서 이 문서에서는 우리가 사용하는 다양한 용어에 대해 자세히 설명합니다.
빠른 용어 정리
|
버블 API
|
Data API 및 Workflow API의 포괄적인 용어 |
| 데이터 API | 데이터베이스에 대한 직접 요청을 처리하는 Bubble API의 일부 |
| 워크플로우 API | API 워크플로를 트리거하는 요청을 처리하는 Bubble API의 일부 |
| API 워크플로우 | 백엔드 편집기에서 만들고 관리하는 워크플로 자체 |
| 백엔드 워크플로우 | 백엔드 편집기에서 사용할 수 있는 다양한 워크플로(API 워크플로, 데이터베이스 트리거, 반복 이벤트 및 사용자 지정 이벤트)에 대한 포괄적인 용어 |
- 버블 API (아래 두 개를 포함)
- 데이터 API
- 워크플로우 API
- 백엔드 워크풀로우 (아래 네 개를 포함)
- API 워크플로우 (API 워크플로우)
- 데이터베이스 트리거 (database trigger)
- 반복 이벤트 (recurring event)
- 사용자 지정 이벤트 (custom event)
(1) Bubble API란 무엇입니까?
Bubble API라는 용어는 Bubble이 다른 애플리케이션에 제공할 수 있는 전체 API 기능을 설명합니다. 즉, 애플리케이션으로 Incoming Call은 Bubble API에 연결됩니다.
- Call이 Bubble API에 도달할 때마다 요청의 지침에 따라 Workflow API 또는 Data API로 나누어서 라우팅 됩니다.
- Bubble API는 Data API 및 Workflow API의 포괄적인 용어로 볼 수 있습니다.
API Connector가 Bubble API의 일부로 간주되지 않는 이유는 무엇입니까?
다른 애플리케이션으로 나가는 연결(Outgoing Call)을 설정하는 데 사용되는 API 커넥터(API Connector)는 Bubble API의 일부가 아닙니다. Bubble 외부로 이동하는 예를 통해 그 이유를 설명할 수 있습니다.
(예시)
업데이트된 날씨 정보를 얻기 위해 Weather API와의 연결을 시작한다고 가정해 보겠습니다.
- 해당 Weather API 서비스는 기능을 위해 하나 이상의 API를 혼합하여 사용할 수도 있습니다.
- 예를 들어 Google Maps API를 사용하여 날씨 정보의 지역주소를 지도 좌표로 변환할 수 있습니다.
- 이 Google Maps API 좌표는 그들이 더 나은 서비스를 제공하는 데 도움이 되지만 날씨정보를 사용하는 당신과 전혀 관련이 없습니다. 따라서 API의 일부가 아닙니다.
- API 설명서에 표시되지 않으며 요청에 대한 응답과 관련되어 있다는 사실을 결코 알 수 없습니다.
Incoming call 요청이 있을 때마다 Bubble의 경우에도 마찬가지입니다.
- 이런 요청을 완료하기 위해 앱의 내부에서 API 커넥터를 사용하여, 타사의 API와 연결하는지 여부는 당신의 앱에 연결을 원하는 사람과 아무런 관련이 없습니다.
- 그들은 단순히 응답을 받기 위해 Bubble API에 연결하기를 원하며 그 상황 뒤에서 일어나는 일은 그들에게 숨겨집니다.
(2) Data API란 무엇입니까?
데이터 API는 데이터베이스에 대한 직접적인 접속을 처리하는 Bubble API의 일부입니다. 이렇게 하면 제삼자가 앱의 데이터베이스에 직접 명령을 보내고 인식할 수 있는 응답을 받을 수 있습니다.
외부에 공개하면 외부 애플리케이션이 다음을 수행할 수 있습니다.
- 데이터베이스에서 레코드 검색 및 읽기
- 새 레코드 만들기
- 레코드 변경
- 레코드 삭제
물론 이 모든 것이 무제한으로 발생하는 것은 아닙니다. 이후 섹션에서 볼 수 있듯이 데이터베이스 보안 사용자설정을 통해서 사용자가 접속 할 수 있는 정보와 명령을 완전히 제어할 수 있습니다.
1. 이러한 데이터베이스 작업은 워크플로우와 어떻게 다릅니까?
- Bubble의 용어에서 워크플로(Workflow)는 Event와 해당 이벤트의 결과로 실행되어야 하는 Action 조합입니다.
2. Workflow API가 데이터베이스를 변경할 수 있다면 Data API가 필요한 이유는 무엇입니까?
- 데이터로 작업하는 대부분의 경우 데이터베이스에 직접 접속하는 것이 합리적인 여러 가지 이유가 있습니다.
1) 동작들이 이미 설정되어 있습니다.
데이터 API는 다른 API가 인식하는 형식으로 다양한 쿼리에 응답하도록 설정됩니다.
- 다음이 내장되어 있습니다.
- 단일 레코드 검색 및 데이터 가져오기
- 사용자기준으로 레코드를 검색하고 페이지가 나눠진 형식으로 데이터 가져오기
- 새로운 데이터를 생성
- 새로운 레코드를 대량으로 생성, 수정, 삭제
워크플로우를 설정하는 데 시간을 들이지 않고도 이 모든 것이 가능합니다.
2) 안전하다.
데이터 API를 사용하면 데이터베이스 보안을 세밀하게 제어할 수 있습니다.
- 인증을 요구함으로써 어떤 클라이언트가 쿼리를 작성하고 있는지 확인할 수 있습니다.
- 해당 클라이언트가 특정 작업을 수행하도록 승인, 데이터 찾기, 특정 필드 숨기기 및 표시, 레코드 만들기, 수정, 삭제
이 모든 것이 하나의 중앙 위치(앱의 개인 정보 보호 규칙)에서 제어되므로 하나의 중앙 대시보드에서 다양한 클라이언트 및 환경에 제한을 적용할 수 있습니다.
3. Data API는 언제 사용해야 합니까?
특정 앱의 데이터베이스에 대한 유연한 접속을 제공하려는 경우, 데이터 API가 더 실용적이고 안전한 API 방법이 되는 몇 가지 예를 살펴보겠습니다.
1) 사례 1: 고객이 외부 웹에서 가입한 기록 남기기
Bubble에서 회사의 CRM을 구축했지만 웹사이트는 Wordpress와 같은 다른 프레임워크에 있다고 가정해 보겠습니다.
- 잠재 고객이 웹사이트의 문의 양식을 사용하여 가입할 때마다 CRM에서 기록을 만들고자 합니다.
- API 요청을 Bubble Data API로 보내도록 Wordpress를 설정하면 Create a Thing Data API 요청을 사용하여 Bubble 데이터베이스에서 새 기록을 생성할 수 있습니다.
2) 사례 2: 인보이스(송장)에 대한 프로젝트 시간 정보
이번에는 Bubble에 프로젝트 관리를 구축했지만 청구서는 외부의 별도 회계 앱에서 처리한다고 가정해 보겠습니다.
- 해당 회계 앱에 데이터베이스를 열면 인보이스(송장)를 생성해야 할 때마다 최신 작업 시간 로그 목록을 얻을 수 있습니다.
- 요컨대, 데이터베이스의 정보를 읽거나 업데이트해야 하고 요청이 전송될 때 필요한 모든 매개변수를 사용할 수 있는 경우 일반적으로 Data API가 더 나은 선택입니다.
(3) Workflow API란 무엇입니까?
지난 글에서 살펴본 것처럼 Workflow API를 사용하면 외부 애플리케이션이 요청을 전송하여 앱에서 API 워크플로를 트리거할 수 있습니다. 워크플로는 수행해야 하는 모든 action 집합을 수행할 수 있습니다.
- Data API와 달리 Workflow API는 데이터베이스를 포함하거나 포함하지 않고 모든 종류의 작업을 수행할 수 있습니다.
- 페이지의 워크플로와 마찬가지로 실행 여부를 결정하는 고유한 조건이 있는 일련의 단계를 설정할 수 있습니다.
- 사용자가 앱의 페이지를 방문하는 것과 동일한 방식으로 Workflow API를 볼 수 있습니다.
- 사용자는 순서대로 실행되는 하나 이상의 작업을 수행하도록 앱에 지시하는 버튼(요청 만들기)을 클릭할 수 있습니다.
1. Data API가 데이터베이스를 변경할 수 있다면 Workflow API가 필요한 이유는 무엇입니까?
워크플로가 데이터베이스 작업을 수행할 수 있지만 데이터베이스 작업이 반드시 워크플로에서 수행되는 것은 아닙니다. Data API보다 Workflow API를 선택하는 데는 여러 가지 이유가 있습니다.
1) 데이터베이스와 관련 없는 작업을 수행할 수 있습니다.
- API 워크플로는 이메일 보내기, 암호 재설정, API 호출 제출 등과 같이 Bubble(플러그인 포함)이 제공할 수 있는 모든 종류의 서버 측 작업을 실행할 수 있습니다.
2) 일련의 작업을 수행할 수 있습니다.
- 워크플로는 순서대로 실행할 수 있는 둘 이상의 작업으로 구성되는 경우가 많으며 각 단계는 필요한 경우 이전 단계에 의존할 수 있습니다.
- Data API는 단순히 요청된 작업을 수행하고 미리 설정된 응답으로 응답하는 반면 Workflow API는 어떤 종류의 무제한 작업을 수행할지에 대한 완전한 유연성을 제공합니다.
- 워크플로는 앱에서 다른 워크플로를 트리거할 수도 있습니다.
3) 맞춤형 응답을 반환할 수 있습니다.
- Data API는 다른 많은 시스템에서 인식되는 형식으로 응답을 다시 보내지만 호출에 대한 응답의 모양을 사용자 지정해야 하는 경우 Workflow API를 사용하여 설정할 수 있습니다.
2. Workflow API는 언제 사용해야 합니까?
데이터 조작 방식에 더 많은 유연성이 필요하거나 데이터베이스와 관련되지 않은 작업을 실행하기 위해 API 호출이 필요할 때마다 사용합니다.
1) 사례 1: 후속 단계
데이터베이스를 변경하려는 경우에도 Workflow API가 올바른 선택이 될 수 있습니다.
예를 들어 앱은 다음을 수행해야 할 수 있습니다.
- 레코드 생성
- 같은 유형의 모든 레코드 총 개수 알기
- 총개수와 함께 요청에 지정된 주소로 이메일을 보내기
이 경우 데이터베이스로 작업하지만 전 단계에 의존하는 몇 가지 특정 작업도 수행하려고 하므로 Workflow API에서 이 작업을 설정하는 것이 좋습니다.
2) 사례 2: 복잡한 조건 사용
작업을 수행해야 하는지 여부를 결정하는 조건에 의존하는 시나리오에서는 Workflow API도 유용합니다.
앱이 다음을 수행해야 한다고 가정해 보겠습니다.
- 새 레코드 생성 (단 , 오늘이 금요일이고 오늘 최대 3개의 레코드가 생성된 경우에만 생성)
- 이와 같은 조건에는 현재 요일을 확인하고 오늘 생성된 레코드의 수를 계산하는 것이 포함됩니다. 이 복잡한 조건은 개인 정보 보호 규칙에서 설정할 수 없으며 조건을 배치할 수 있는 API 워크플로가 필요합니다.
Data API와 비교해서 중요한 점은, Data API에서는 미리 정해진 동작(명령어)만 수행할 수 있다면 Workflow API에서는 개발자가 원하는 조건과 데이터를 순서에 따라서 동작하게 만들 수 있다는 처이점이 있습니다.
3. Workflow API라고도 하고 API Workflow라고도 하는 이유는 무엇입니까?
이 두 용어는 실제로 밀접하게 관련되어 있지만 서로 다른 것을 의미합니다.
1) Workflow API는 워크플로를 처리하는 Bubble API의 일부입니다.
Workflow API는 API 워크플로를 처리하는 Bubble API 부분의 포괄적인 용어입니다.
2) API Workflow는 백엔드 워크플로 편집기에서 설정하는 워크플로 자체입니다.
워크플로우는 프런트 워크플로우와 백엔드 워크플로우가 각각 따로 설정하게 되어있습니다.
따라서 Workflow API는 API Workflows로 구성되며 API Workflows는 Bubble의 Workflow API의 일부입니다.
(4) Backend Workflow Editor : 백엔드 워크플로 편집기
Bubble의 백엔드 워크플로 편집기는 백엔드 워크플로를 만들고 관리하는 Bubble 편집기의 한 섹션입니다.
Backend Workflow(백엔드 워크플로)와 API 워크플로의 차이점은 무엇인가요?
: 백엔드 워크플로는 백엔드 편집기에서 생성할 수 있는 모든 유형의 워크플로를 포괄하는 용어입니다.
버블의 백엔드 워크플로는 네 가지 종류의 이벤트를 제공합니다.
- API Workflow는 Workflow API에 속함
- Database trigger Event
- Recurring Event
- Custom Event
API 워크플로는 Workflow API에 속하며 나머지는 다른 용도로 사용되는 내부 도구입니다.
이들 모두의 공통점은 서버 측에서 실행된다는 것입니다.
이는 서버 측의 동작으로, 앱의 페이지를 방문하지 않고 Bubble 서버에서 실행할 수 있음을 의미합니다.
