이 문서에서는 RBM 플랫폼이 메시지 전송 및 기타 API 상호작용을 처리하는 방법을 명확히 설명하여 동기식 작업과 비동기식 작업을 구분합니다.
RBM API 상호작용은 일반적으로 HTTP 수준에서 동기식 요청-응답 패턴을 따릅니다. 그러나 많은 API 호출의 결과, 특히 메시지 전송은 웹훅을 통해 비동기식으로 처리됩니다. 자세한 내용은 다음 섹션을 참고하세요.
메시지 전송: 동기식 요청, 비동기식 전송
phones.agentMessages.create API 요청은 API 관점에서 동기식으로 처리됩니다. RBM 플랫폼에 HTTP 요청을 하면 서버는 거의 즉시 표준 HTTP 상태 코드(예: 200 OK 또는 오류)로 응답하여 요청이 수신되었는지 여부와 유효성을 나타냅니다.
그러나 최종 사용자에게 메시지를 실제로 전송하는 작업은 비동기식으로 처리됩니다. 이 프로세스에 영향을 줄 수 있는 요인은 다음과 같습니다.
수신자 상태: 사용자가 오프라인 상태이거나 배터리가 없거나 RCS가 사용 설정되지 않았을 수 있습니다.
네트워크 상태: 이동통신사 네트워크 문제로 인해 메시지 전송이 지연되거나 전송되지 않을 수 있습니다.
RBM 플랫폼은 webhooks을 통해 메시지 전송 상태 업데이트 (예: 전송 확인 및 수신 확인)를 비동기식으로 제공합니다.
따라서 초기 API 요청은 동기식이지만 비동기식 웹훅 이벤트를 사용하여 메시지 전송을 추적해야 합니다. phones.agentMessages.create 응답에서 즉시 전송 상태를 확인할 수 있는 것은 아닙니다.
기타 RBM API 상호작용
대부분의 다른 HTTP 기반 RBM API도 동기식 요청-응답 모델로 작동합니다. 이러한 API는 요청 상태 (성공 또는 오류)를 나타내는 즉각적인 HTTP 응답을 제공합니다. 그러나 요청은 동기식이지만 요청으로 인한 작업에는 비동기 프로세스가 포함될 수 있습니다.
예를 들어 상담사 정보를 업데이트하기 위한 API 호출에 대한 응답이 성공했다고 해서 업데이트가 모든 위치에 즉시 반영되는 것은 아닙니다. 짧은 전파 지연이 있을 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-02-10(UTC)"],[[["\u003cp\u003eRBM API interactions use a synchronous request-response model at the HTTP level, providing immediate feedback on request validity.\u003c/p\u003e\n"],["\u003cp\u003eMessage delivery in the RBM platform is processed asynchronously, relying on webhooks for updates due to factors like recipient status and network conditions.\u003c/p\u003e\n"],["\u003cp\u003eWhile the initial API request for sending messages is synchronous, delivery and read receipts are provided asynchronously through webhook events.\u003c/p\u003e\n"],["\u003cp\u003eOther RBM API interactions follow a synchronous pattern for request handling, but resulting actions may involve asynchronous processes with potential delays.\u003c/p\u003e\n"],["\u003cp\u003eThe RBM platform delivers various asynchronous events, such as incoming user messages, delivery receipts, and conversation updates, through a designated webhook endpoint.\u003c/p\u003e\n"]]],[],null,["# Synchronous and asynchronous operations in RBM\n\nThis document clarifies how the RBM platform handles message sending and other\nAPI interactions, distinguishing between synchronous and asynchronous\noperations.\n\nRBM API interactions generally follow a synchronous request-response pattern at\nthe HTTP level. However, the results of many API calls, especially message\ndelivery, are handled asynchronously through webhooks. Refer to the following\nsections for details.\n\nMessage sending: Synchronous request, asynchronous delivery\n-----------------------------------------------------------\n\nThe [`phones.agentMessages.create`](/business-communications/rcs-business-messaging/reference/rest/v1/phones.agentMessages/create)\nAPI request is processed **synchronously** from the API\nperspective. When you make an HTTP request to the RBM platform, the server\nresponds almost immediately with a standard HTTP status code\n(like `200 OK` or an error) to indicate whether the request was\nreceived and is valid.\n\nHowever, the actual delivery of the message to the end user is\nprocessed **asynchronously**. The following factors can affect this process:\n\n- **Recipient status**: The user might be offline, have an empty battery, or not have RCS enabled.\n- **Network conditions**: Carrier network issues can delay or prevent message delivery.\n\nThe RBM platform provides message delivery status updates (like delivery\nreceipts and read receipts) asynchronously through\n[webhooks](/business-communications/rcs-business-messaging/guides/integrate/webhooks).\nTherefore, while the initial API request is synchronous, you should rely on\nasynchronous webhook [events](/business-communications/rcs-business-messaging/guides/build/events#agent-generated_events)\nto track message delivery. Don't expect immediate confirmation of delivery\nstatus from the\n[`phones.agentMessages.create`](/business-communications/rcs-business-messaging/reference/rest/v1/phones.agentMessages/create)\nresponse.\n\n### Other RBM API interactions\n\nMost other HTTP-based RBM APIs also operate with a synchronous request-response\nmodel. These APIs provide an immediate HTTP response that indicates the status\nof the request (success or error). However, while the request is synchronous,\nthe actions resulting from the request might involve asynchronous processes.\nFor example, a successful response to an API call to update agent information\ndoesn't mean the update is instantly reflected everywhere; there might be a\nshort propagation delay.\n\nWebhook endpoint: Asynchronous events\n-------------------------------------\n\nThe following [events](/business-communications/rcs-business-messaging/guides/build/events#agent-generated_events)\nare delivered asynchronously to your [webhook](/business-communications/rcs-business-messaging/guides/integrate/webhooks)\nendpoint:\n\n- **Incoming user messages** : The RBM platform pushes incoming user messages to your webhook endpoint. Be sure to [verify incoming messages](/business-communications/rcs-business-messaging/guides/integrate/webhooks#verify_incoming_messages).\n- **Delivery and read receipts**: Notifications of message delivery and read status are sent through webhooks.\n- **Conversation events**: Some conversation-related events, such as typing indicators, are sent through webhooks.\n- **Message expiration and revocation events**: The RBM platform sends events to confirm whether an expired message was successfully revoked."]]
