Amazon Lex provides both build and runtime endpoints. Each endpoint provides a set of\n * operations (API). Your conversational bot uses the runtime API to understand user utterances\n * (user input text or voice). For example, suppose a user says \"I want pizza\", your bot sends\n * this input to Amazon Lex using the runtime API. Amazon Lex recognizes that the user request is\n * for the OrderPizza intent (one of the intents defined in the bot). Then Amazon Lex engages in\n * user conversation on behalf of the bot to elicit required information (slot values, such as\n * pizza size and crust type), and then performs fulfillment activity (that you configured when\n * you created the bot). You use the build-time API to create and manage your Amazon Lex bot. For\n * a list of build-time operations, see the build-time API, .
\n */\nvar LexRuntimeServiceClient = /** @class */ (function (_super) {\n __extends(LexRuntimeServiceClient, _super);\n function LexRuntimeServiceClient(configuration) {\n var _this = this;\n var _config_0 = __assign(__assign({}, __ClientDefaultValues), configuration);\n var _config_1 = resolveRegionConfig(_config_0);\n var _config_2 = resolveEndpointsConfig(_config_1);\n var _config_3 = resolveAwsAuthConfig(_config_2);\n var _config_4 = resolveRetryConfig(_config_3);\n var _config_5 = resolveHostHeaderConfig(_config_4);\n var _config_6 = resolveUserAgentConfig(_config_5);\n _this = _super.call(this, _config_6) || this;\n _this.config = _config_6;\n _this.middlewareStack.use(getAwsAuthPlugin(_this.config));\n _this.middlewareStack.use(getRetryPlugin(_this.config));\n _this.middlewareStack.use(getContentLengthPlugin(_this.config));\n _this.middlewareStack.use(getHostHeaderPlugin(_this.config));\n _this.middlewareStack.use(getLoggerPlugin(_this.config));\n _this.middlewareStack.use(getUserAgentPlugin(_this.config));\n return _this;\n }\n LexRuntimeServiceClient.prototype.destroy = function () {\n _super.prototype.destroy.call(this);\n };\n return LexRuntimeServiceClient;\n}(__Client));\nexport { LexRuntimeServiceClient };\n//# sourceMappingURL=LexRuntimeServiceClient.js.map","import { __extends } from \"tslib\";\nimport { PostTextRequest, PostTextResponse } from \"../models/models_0\";\nimport { deserializeAws_restJson1PostTextCommand, serializeAws_restJson1PostTextCommand, } from \"../protocols/Aws_restJson1\";\nimport { getSerdePlugin } from \"@aws-sdk/middleware-serde\";\nimport { Command as $Command } from \"@aws-sdk/smithy-client\";\n/**\n *Sends user input to Amazon Lex. Client applications can use this API to send requests to\n * Amazon Lex at runtime. Amazon Lex then interprets the user input using the machine learning model it\n * built for the bot.
\n * In response, Amazon Lex returns the next message to convey to the user an\n * optional responseCard to display. Consider the following example messages:
For a user input \"I would like a pizza\", Amazon Lex might return a response with a\n * message eliciting slot data (for example, PizzaSize): \"What size pizza would you like?\"\n *
\n *After the user provides all of the pizza order information, Amazon Lex might return a\n * response with a message to obtain user confirmation \"Proceed with the pizza order?\".\n *
\n *After the user replies to a confirmation prompt with a \"yes\", Amazon Lex might return\n * a conclusion statement: \"Thank you, your cheese pizza has been ordered.\".
\n * Not all Amazon Lex messages require a user response. For example, a conclusion statement\n * does not require a response. Some messages require only a \"yes\" or \"no\" user response. In\n * addition to the message, Amazon Lex provides additional context about the message\n * in the response that you might use to enhance client behavior, for example, to display the\n * appropriate client user interface. These are the slotToElicit,\n * dialogState, intentName, and slots fields in the\n * response. Consider the following examples:
If the message is to elicit slot data, Amazon Lex returns the following context\n * information:
\n *\n * dialogState set to ElicitSlot
\n * intentName set to the intent name in the current context
\n * slotToElicit set to the slot name for which the message is\n * eliciting information
\n * slots set to a map of slots, configured for the intent, with currently\n * known values
If the message is a confirmation prompt, the dialogState is set to\n * ConfirmIntent and SlotToElicit is set to null.
If the message is a clarification prompt (configured for the intent) that indicates\n * that user intent is not understood, the dialogState is set to ElicitIntent\n * and slotToElicit is set to null.
In addition, Amazon Lex also returns your application-specific\n * sessionAttributes. For more information, see Managing Conversation Context.
Sends user input (text or speech) to Amazon Lex. Clients use this API to send text and audio\n * requests to Amazon Lex at runtime. Amazon Lex interprets the user input using the machine learning model\n * that it built for the bot.
\n *The PostContent operation supports audio input at 8kHz and 16kHz. You can use\n * 8kHz audio to achieve higher speech recognition accuracy in telephone audio applications.
In response, Amazon Lex returns the next message to convey to the user. Consider the following\n * example messages:
\n * For a user input \"I would like a pizza,\" Amazon Lex might return a response with a message\n * eliciting slot data (for example, PizzaSize): \"What size pizza would you\n * like?\".
After the user provides all of the pizza order information, Amazon Lex might return a\n * response with a message to get user confirmation: \"Order the pizza?\".
\n *After the user replies \"Yes\" to the confirmation prompt, Amazon Lex might return a\n * conclusion statement: \"Thank you, your cheese pizza has been ordered.\".
\n * Not all Amazon Lex messages require a response from the user. For example, conclusion\n * statements do not require a response. Some messages require only a yes or no response. In\n * addition to the message, Amazon Lex provides additional context about the message in\n * the response that you can use to enhance client behavior, such as displaying the appropriate\n * client user interface. Consider the following examples:
If the message is to elicit slot data, Amazon Lex returns the following context\n * information:
\n *\n * x-amz-lex-dialog-state header set to ElicitSlot\n *
\n * x-amz-lex-intent-name header set to the intent name in the current\n * context
\n * x-amz-lex-slot-to-elicit header set to the slot name for which the\n * message is eliciting information
\n * x-amz-lex-slots header set to a map of slots configured for the intent\n * with their current values
If the message is a confirmation prompt, the x-amz-lex-dialog-state\n * header is set to Confirmation and the x-amz-lex-slot-to-elicit\n * header is omitted.
If the message is a clarification prompt configured for the intent, indicating that\n * the user intent is not understood, the x-amz-dialog-state header is set to\n * ElicitIntent and the x-amz-slot-to-elicit header is omitted.\n *
In addition, Amazon Lex also returns your application-specific sessionAttributes.\n * For more information, see Managing Conversation Context.