Odbieranie komunikatów z bota w interfejsie API Direct Line 1.1
Ważne
W tym artykule opisano sposób odbierania komunikatów z bota przy użyciu interfejsu API Direct Line 1.1. Jeśli tworzysz nowe połączenie między aplikacją kliencką a botem, zamiast tego użyj interfejsu API Direct Line 3.0.
Korzystając z protokołu Direct Line 1.1, klienci muszą sondować interfejs w celu odbierania HTTP GET komunikatów.
Pobieranie komunikatów za pomocą polecenia HTTP GET
Aby pobrać komunikaty dla określonej konwersacji, wydaj GET żądanie do api/conversations/{conversationId}/messages punktu końcowego, opcjonalnie określając watermark parametr w celu wskazania najnowszego komunikatu widocznego przez klienta. Zaktualizowana watermark wartość zostanie zwrócona w odpowiedzi JSON, nawet jeśli nie zostaną uwzględnione żadne komunikaty.
Poniższe fragmenty kodu zawierają przykład żądania Pobierania komunikatów i odpowiedzi. Odpowiedź Pobierz komunikaty zawiera watermark wartość właściwości MessageSet. Klienci powinni stronicować dostępne komunikaty, rozwijając watermark wartość, dopóki nie zostaną zwrócone żadne komunikaty.
Żądanie
GET https://directline.botframework.com/api/conversations/abc123/messages?watermark=0001a-94
Authorization: Bearer RCurR_XV9ZA.cwA.BKA.iaJrC8xpy8qbOF5xnR2vtCX7CZj0LdjAPGfiCpg4Fv0
Reakcja
HTTP/1.1 200 OK
[other headers]
{
"messages": [
{
"conversation": "abc123",
"id": "abc123|0000",
"text": "hello",
"from": "user1"
},
{
"conversation": "abc123",
"id": "abc123|0001",
"text": "Nice to see you, user1!",
"from": "bot1"
}
],
"watermark": "0001a-95"
}
Zagadnienia dotyczące chronometrażu
Mimo że Direct Line jest wieloczęściowym protokołem z potencjalnymi przerwami w czasie, protokół i usługa została zaprojektowana tak, aby ułatwić tworzenie niezawodnego klienta. Właściwość watermark , która jest wysyłana w odpowiedzi Pobierz komunikaty, jest niezawodna. Klient nie przegapi żadnych komunikatów, o ile odtwarza znak wodny dosłowny.
Klienci powinni wybrać interwał sondowania zgodny z ich zamierzonym użyciem.
Aplikacje typu service-to-service często używają interwału sondowania 5s lub 10s.
Aplikacje klienckie często używają interwału sondowania 1s i wystawiają dodatkowe żądanie ~300 ms po każdym komunikacie wysyłanym przez klienta (aby szybko pobrać odpowiedź bota). To opóźnienie 300 ms powinno być dostosowane na podstawie szybkości i czasu tranzytu bota.