AWS API Gateway body map wildcard

Я установил API на AWS API Gateway, который использует согласование контента, чтобы обеспечить два способа, с помощью которых можно получить некоторые данные.AWS API Gateway body map wildcard

Моя проблема в том, что, поскольку default Content-Type header appears to be application/json, пример разметки ниже возвращается как application/json и поэтому отображается просто, а не отображается.

Шаблон сопоставления тела text/html пытается точно определить заголовок Accept, отправленный браузером. Например, отправляет Chrome

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Который явно !== text/html. При этом, когда я отправляю запрос, такой как выше, отображается правильный ответ, но отображается неправильный заголовок типа контента.

Мои варианты, казалось бы,

найти способ настройки по умолчанию для text/html
Найти средства, с помощью которых можно сделать подстановочные или регулярное выражение работы. Например. text/*

Я пробовал это безрезультатно, но я надеюсь, что у меня что-то не хватает.

примеры отклика

Один отвечает JSON (Accept: application/json)
```
{ 
    "id": "d4ef7d3f-f2..." 
} 
```

Другой разметки и некоторые JS, который посылает postMessage. Accept: text/html

<!DOCTYPE html> 
<html lang="en"> 
    <head> 
    <meta charset="UTF-8"> 
    <title>Example</title> 
    </head> 
    <body> 
    <script> 
     parent.postMessage({"id": "d4ef7d3f-f2..."}, "...", window); 
    </script> 
    </body> 
</html>

Суть API шлюза Кураж

https://gist.github.com/benswinburne/3a212c936e1d97fe8e17352269d6edb6

источник

2016-09-13 Ben Swinburne

API поддержки шлюза для переговоров контента в настоящее время ограничено.

Я предлагаю не предлагать контент напрямую с помощью API Gateway, а вместо этого использовать тонкий клиентский уровень для управления вызовами в Gateway API. Это позволяет, кроме всего прочего, полностью контролировать заголовки Accept/Content-Type.

В качестве примера мы обычно видим простые SPA, обычно размещенные на сайте S3, с клиентом javascript для вызова API Gateway.

В качестве альтернативы вы можете переопределить сопоставление по умолчанию для заголовка Content-Type в ответе метода.

Редактировать, чтобы объяснить, как я реализовал его на основе этого ответа.

ответ метод Add Content-Type
Добавить отображение заголовка ответа интеграции
```
Content-Type => integration.response.body.contentType 
```
Убедитесь, что пары заголовка отображается в шаблоне отображения тела в запросе интеграции для всех типов содержимого вы хотите купить с помощью.
Обновление лямбда-функция для возврата имущества типа контента, в приведенном ниже примере

exports.handler = (event, context, callback) => { 
    var contentType = this.negotiateContentType(event.params.header.Accept); 

    // abridged 

    context.done(null, {contentType}); // abridged 
}; 

exports.negotiateContentType = (header) => { 
    var contentType = 'text/html'; 

    if (header.match(/json/ig)) { 
     contentType = 'application/json'; 
    } 

    return contentType; 
}

Если вы не хотите, тип содержимого в своем ответе, вы можете установить шаблон шаблона тела для каждого типа контента в ответ интеграции.

Например

// All properties 
$input.json('$') 

// Custom output 
{ 
    "myproperty": $input.json('$.myproperty') 
}

источник

2016-09-13 22:26:30

Благодаря Райан - ваше последнее утверждение дало мне идею, над которой я добавил в свой ответ, чтобы полностью объяснить, как я получил его на работу для других. К сожалению, использование SPA в качестве прокси не соответствовало бы моим потребностям, так как есть 302 переадресации, а также фактический контент, который все должно быть в одном домене. Прокси-сервер означает, что мне придется перенаправить браузер после загрузки содержимого и проксирования запроса с помощью JS или мета-обновления, которое будет слишком медленным. Кроме того, удаление cookie становится проблематичным с этим подходом, если я не перенаправляю еще один URL-адрес. –

AWS API Gateway body map wildcard

ответ

Смежные вопросы