Ваш JSON в пункте 1 неверен .. некоторые закрывающие скобки неверны

ся мой вопрос может быть немного похожк этому.

У меня есть API-интерфейс в моем API-шлюзе, и я выполняю HTTP-прокси до конечной точки, которая является файлами POST multipart / form-data.

Если я вызываю конечную точку http напрямую (не через шлюз API) - используя почтальон, он работает, как и ожидалось, однако использование конечной точки шлюза API (через почтальон) завершается неудачно.

Я сравнил оба запроса (через журналы Fiddler и CloudWatch), которые кажутся идентичными:

Запрос на прямой вызов API (рабочий):

POST https://domainname/api/v1/documents HTTP/1.1
Host: api.service
Connection: keep-alive
Content-Length: 202
Authorization: AuthToken
Postman-Token: a75869d6-1d64-6b9f-513d-a80ac192c8e1
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
docMetaInfo: some extra data needed
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryB85rsPlMffA2fziS
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8

------WebKitFormBoundaryB85rsPlMffA2fziS
Content-Disposition: form-data; name=""; filename="Test.txt"
Content-Type: text/plain

This is a test Text File
------WebKitFormBoundaryB85rsPlMffA2fziS--

Запрос от шлюза API (не работает):

POST https://GATEWAY_domainname/api/v1/documents HTTP/1.1
Host: api-Gateway.service
Connection: keep-alive
Content-Length: 202
Authorization: AuthToken
Postman-Token: e25536fa-3dfa-ddcb-8ca6-3f3552d2bc40
Cache-Control: no-cache
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
docMetaInfo: some extra data needed
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarybX9MyWBsuLGm6QIC

x-api-key: *********************
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8

------WebKitFormBoundarybX9MyWBsuLGm6QIC
Content-Disposition: form-data; name=""; filename="Test.txt"
Content-Type: text/plain

This is a test Text File
------WebKitFormBoundarybX9MyWBsuLGm6QIC--

Я попробовал несколько вещей со стороны шлюза, включая изменениеIntegration Request сопоставить новое тело для того же типа контента, не повезло.

Насколько я знаю, мне нужно толькоpassthrough этот вызов, следовательно, почему он становится немного запутанным - не должно быть необходимости в манипулировании / перехвате данных?

Я получаю ошибку 400 - неправильный запрос (жалоба наfile не найден), но, как видно из запроса, он есть.

Есть идеи?

РЕДАКТИРОВАТЬ Журналы из CloudWatch на том же APIGateway POST

Ошибка все еще 400 - файл не найден

Ответы на вопрос(3)

Ваш ответ на вопрос