Adding an API Gateway to your application is a good way to centralize some work you usually have to do for all of your API routes, like authentication or validation. But like every software system, it comes with its own problems. Solving errors in the cloud isn’t always straightforward, and API Gateway isn’t an exception.
What is AWS API Gateway?
AWS API Gateway is an HTTP gateway, and as such, it uses the well-known HTTP status codes to convey its errors to you. Errors in the range of 400 to 499 usually point to a problem with the API client, and errors in the range of 500 to 599 mean something on the server is wrong.
This is a rule of thumb, and if you don’t have any logic bugs in your backend, it holds. But nobody is perfect, and so it could happen that a 400 code still means your client is right and your backend is wrong. But let’s not get ahead of us and look into the errors, case by case.
Handling API Gateway 400 Error: Bad Request
The 400 error is probably the broadest of the client errors. Depending on what AWS service API Gateway is integrating with for the URL, it can mean many things.
A retry usually doesn’t help because it means the request doesn’t match what that specific API Gateway integration is expecting, and sending it again wouldn’t change that.
Reasons for this error include:
- Invalid JSON, like missing commas and such.
- Missing fields, when the upstream service has required a field you missed
- Wrong data types, when you send a string instead of a number
- Invalid characters, like using whitespaces in identifiers
You can find the required fields, expected data types, and valid characters for a field in the documentation of the AWS service you integrated with API Gateway.
Handling API Gateway 403 Error: Access Denied
This error is also known as “Forbidden” and implies some permission issue. Every resource you provision in AWS has an IAM role. This role defines what that resource can access and how it can access it. Your API Gateway has an IAM role too, and if it’s not configured correctly, it can prevent API Gateway from integrating with a service.
Again, a retry doesn’t help here.
If you use end-user authentication with AWS Cognito, every request will get a temporary role related to the Cognito user who issued the request. If this role isn’t configured correctly, it can also prevent users from accessing specific resources.
If you’re using a custom Lambda authorizer in your API Gateway, this error code could also relate to a problem in that Lambda function.
Handling API Gateway 404 Error: Not Found
The 404 error usually means your URL is wrong. Probably in 99% of the cases.
If you’re sure the URL is right, but you’re still getting the error, it could also be related to the service you integrate with API Gateway when you try to access data in these services that aren’t there.
A retry only solves this problem if the 404 comes from a race condition. When you told the backend to create a resource, you wanted to access it with the next request, but the request was too soon, and the thing you created isn’t there yet. Such issues happen with eventually consistent data stores like DynamoDB.
The more expensive consistent reads of DynamoDB usually solve this problem.
Handling API Gateway 409 Error: Conflict
The 409 status indicates that your request is trying to do something that conflicts with a resource’s current state. A resource could be a record in a DynamoDB table that’s integrated with your API. It could be that you tried to create a resource with a specific ID that already exists.
The 409 error is also related to something called a callers reference. This reference is used to mark a request, so it gets only executed once. If you send it and don’t get an answer from the API, you don’t know if the request got lost before or after it made its way to the API. This usually leads to a retry. If the API hasn’t seen the caller reference the last time, it will simply execute it and respond with an appropriate status code. But if the API has seen the caller reference, it gives you a 409 status code to indicate your request was already accepted when you sent it the first time.
So, a retry usually won’t solve this problem and can even be the source of this error code in the first place.
Handling API Gateway 429 Error: Limit Exceeded
There are two 429 errors you could get from API Gateway. The first one is called “Limit Exceeded Exception,” which indicates that you went over an API quota.
API Gateway allows access control via API keys. When creating such a key, you can also define a usage quota such as 1000 requests per week. If this quota is reached, the API gateway will respond with a 429.
Normally a retry doesn’t solve this problem. You either have to increase the quota for the key, or you have to wait until the next usage period starts.
The best way to get around this issue is to keep your API requests monitored and counted. Check how many requests you send and if you really need to send so many. You can also try to cache responses so that you can reuse them instead of sending duplicate requests that count to your key’s quota.
Handling API Gateway 429 Error: Too Many Requests
The second 429 error is of temporary nature. You would get it if you sent too many requests at once. For example, if you have an API endpoint connected to a Lambda function, this function has a predefined limit of 1000 concurrent invocations.
If you send 1001 in parallel, you get a 429 error, but depending on the time this Lambda function takes to handle a request, you can retry some time later and get a free slot again.
Again, API keys can have limits too. If you got a key that only allows for 10 concurrent requests, the upstream service could handle millions, but your 11th parallel request wouldn’t go through.
Try to monitor your request so you see when they get close to the limit of your services, and try to cache requests on your clients so that they won’t hammer the API.
Did you know Dashbird will detect API Gateway issues and alert them to you?
Handling API Gateway 500 Error: Internal Server Error
The 500 status code might be the most used and most generic HTTP error on this planet. If you get it from an API endpoint that integrates with AWS Lambda, it usually means your code buggy.
The next source for this error is inconsistent error mapping. Many of the errors we talked about here can become a 500 error when finally landing on your client as a response. You’ll get a “limit exceeded,” but it will have a 500 status code instead of 429. So you have to extract the right error out of this response, check what the real cause is, and then look at how to solve it.
Since the error can be anything really, a retry can technically solve that problem, but usually, it doesn’t.
If you monitor your system carefully and get one of these every few million requests, it could be that cosmic rays flipped some bits or whatever. Still, if you see a 500 status code more often than that, it’s crucial to investigate; it can very well point to an inconsistency that will blow up sooner or later.
Handling API Gateway 502 Error: Bad Gateway
A 502 error code is related to the service your API Gateway integrates with. It means that API Gateway couldn’t understand the response.
For example, when you throw an error in a Lambda function or the resolved value has an invalid structure, it can lead to a 502 error. If you used EC2 or ECS/EKS, it could also be that API Gateway can’t connect to the VM or container because they aren’t running (correctly).
Retries can help, especially when integrated services are currently restarting.
Handling API Gateway 503 Error: Service Unavailable
If you see a 503 error, most of the time, it means the service you’re integrating takes too long to answer.
API Gateway has a maximum hard limit of 30 seconds timeouts. If your service can’t respond in under 30 seconds, API Gateway will assume it’s unavailable and stop waiting.
If the work your service does takes around 30 seconds, you should handle things asynchronously. Respond with a 202 accepted and give the client a way to fetch the results later.
If your service usually responds well below 30 seconds but only occasionally goes over the limit, you can solve the problem with retries.
Handling API Gateway 504 Error: Endpoint Request Timed-out
The 504 status code is a bit like 503. The difference is that 504 indicates a DNS or network problem, and 503 indicates a performance problem.
Again, this can be temporary, and a retry might solve it. After all, the internet isn’t 100% stable.
But you usually see that issue when an integrated service isn’t running, or you got the IP or hostname wrong, either because you entered the wrong or they changed somehow after you entered them.
Conclusion
We went over all the API Gateway errors you will probably encounter, and like with anything debugging-related, things can get quite messy — especially if you have countless rows of logs to sift through.
The good news is that Dashbird integrates well with API Gateway monitoring and delivers actionable insights straight to your Slack or SMS when things go awry.
Dashbird also works with AWS as their Advanced Technology Partner and uses the AWS Well-Architected Framework to ensure you’re on track to performance and cost optimization. If you want to try Dashbird out, it’s free for the first 1 million invocations per month.
Read our blog
Introducing easy custom event monitoring for serverless applications.
Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.
Why and How to Monitor Amazon OpenSearch Service
One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.
Why and How to Monitor AWS Elastic Load Balancing
Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!
More articles
#amazon-web-services #cors #aws-api-gateway
#amazon-веб-сервисы #cors #aws-api-gateway
Вопрос:
У меня есть приложение, написанное на React JS, работающее на localhost, которое выполняет вызовы API для API Gateway в AWS. API Gateway пересылает запросы в лямбда-функцию, которая возвращает ответ. Я включил CORS на стороне AWS. В данный момент всякий раз, когда я нажимаю кнопку «запросить» в приложении, я получаю ответ от шлюза. Вот мой текущий код на Python:
import json
def lambda_handler(event, context):
response = {}
response['result'] = "Success"
response['message'] = "Updated successfully!"
return {
'headers': {
'Access-Control-Allow-Headers': 'Content-Type',
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST'
},
"body": json.dumps(response)
}
А вот основная часть запроса:
{
"ID": "1101",
"RequestDate": "2021-02-28"
}
Это работает нормально. Я получаю значение «сообщение» из этого ответа и могу отобразить его без проблем.
Далее я хочу отобразить информацию, содержащую некоторые данные, поступающие из запроса. Например, вместо Updated successfully я хотел бы получить RequestDate из запроса и вернуть Updated successfully on 2021-02-28 .
Я добавил эти две строки:
def lambda_handler(event, context):
body = json.loads(event['body'])
request_date = body['RequestDate']
response = {}
response['result'] = "Success"
response['message'] = "Updated successfully!"
return {
'headers': {
'Access-Control-Allow-Headers': 'Content-Type',
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST'
},
"body": json.dumps(response)
}
Как только я внесу это изменение, я получу следующий код в своем приложении:
Access to fetch at url from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Это происходит только тогда , когда я добавляю request_date = body['RequestDate'] . Я попробовал вернуть только тело, и оно тоже работало нормально.
В моем приложении react js я также добавляю следующие заголовки:
async callAPI(url, method, data) {
let result = await fetch(url, {
method: method,
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': '*'
},
body: JSON.stringify({
data
})
})
return result.json().then(body => this.notify(body['message']));
}
Я попытался включить CORS и снова развернуть ресурс, но безрезультатно. Я добавил Access-Control-Allow-Origin к разрешенным заголовкам в AWS. Как я уже упоминал, он отлично работает с методом post до добавления этой одной строки. Что здесь может быть не так и как я могу это исправить?
РЕДАКТИРОВАТЬ: Еще одна вещь. Я получаю эту ошибку только из моего приложения, запущенного на localhost. Скручивание или использование любого REST-клиента работает нормально.
EDIT2: Добавлен код выборки
Комментарии:
1. можете ли вы попробовать вернуться
'Access-Control-Allow-Headers':'*'из lambda?2. Пробовал сейчас, все то же самое
Ответ №1:
Настройка CORS в Lambda зависит от того, как вы настраиваете API Gateway. API Gateway имеет несколько режимов [REST, HTTP, WebSocket]. В случае REST API Gateway выполняет некоторую предварительную обработку входящего запроса, например проверку параметров, перед передачей в Lambda. HTTP-прокси — это просто переход к Lambda, а Websockets на самом деле не для этого обсуждения.
Я предполагаю, что это связано с тем, что вы используете API Gateway в стандартной конфигурации и не включили CORS на API Gateway. Приведенный выше код будет работать для шлюза API, настроенного для HTTP.
Если вы используете CDK или CloudFormation, то вы должны настроить CORS там, иначе проще всего использовать консоль.
Перейдите к своему API в консоли AWS, выберите ресурсы, выберите свой метод или услугу, в меню действия включите CORS. А затем опубликуйте свой обновленный API.
Вот ссылка на документацию AWS, в которой изложено, как это сделать.
Несколько советов: при тестировании конечных точек через браузер лучше не использовать Localhost или 127.0.0.1, это может привести к непредвиденным последствиям. Отредактируйте свой файл hosts и укажите себе доменное имя, а затем используйте это доменное имя вместо него.
CORS существует не просто так, чтобы предотвратить межсайтовый скриптинг или атаки межсайтового происхождения. Попробуйте не использовать *, тестирование обязательно, но производство нет. Если у вас есть код, скажем, на S3, а ваши службы REST, скажем, на API Gateway, вы можете подключиться к CloudFront с использованием того же источника и сообщить CloudFront о необходимости пересылки на основе URL (например, / API) в APIGateway, а другой — в S3. Таким образом, все имеет один и тот же домен.
Комментарии:
1. Я включил CORS, как описано в вашем ответе. На данный момент мне просто нужно, чтобы это работало, мне не нужно беспокоиться о безопасности.
Ответ №2:
Это то, что у меня есть на моем сервере, и оно работает нормально. Использование выборки во внешнем интерфейсе.
Код сервера:
import json
result = {"hello": "world"}
return {
'statusCode': 200,
'headers': {
'Content-Type': 'application/json',
"Access-Control-Allow-Origin": "*"
},
'body': json.dumps(result)
}
Интерфейсный код с использованием ES6
url = "Your url"
path = "Your desired path"
data = {"hello": "world"}
const response = await fetch(url path, {
method: "POST",
cache: "no-cache",
mode: "cors",
body: JSON.stringify(data),
});
Комментарии:
1. То, что вы опубликовали, работает и для меня. Ошибка возникает, когда я пытаюсь прочитать какие-либо данные из запроса, полученного сервером. Добавление
body = json.loads(event['body']) request_date = body['RequestDate']— это то, что его нарушает. Вы пытались получить какие-либо данные из запроса и отобразить их?2. Я полагаю, вы не включаете «RequestDate» в свой запрос на выборку. Можете ли вы поделиться своим кодом запроса на выборку? Кроме того, вы получаете ошибку CORS, потому что ваша функция не выполняется и возвращает сообщение об ошибке. Поместите его в
try: except:блок, чтобы предотвратить это.3. Я добавил код выборки. включен параметр «Дата запроса». Как только я закомментирую «request_date = body [‘RequestDate’]» на стороне сервера, я перестаю получать ошибку и получаю правильный ответ, но затем я не могу добавить дату из запроса в ответ.
Ответ №3:
Добавить StatusCode внутри ответа от lambda
return {
'statusCode': 200,
'headers': {
'Access-Control-Allow-Headers': 'Content-Type',
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST'
},
'body': json.dumps(response)
}
В случае, если в вашем lambda есть какая-либо ошибка, он вернет ответ по умолчанию 5XX без каких-либо заголовков CORS, и в таких случаях браузер будет жаловаться на то, что заголовки cors не найдены.
Вы можете добавить свой текущий код в try блок, а в except блоке вы можете распечатать ошибку и вернуть некоторый ответ по умолчанию, как показано ниже
return {
'statusCode': 500,
'headers': {
'Access-Control-Allow-Headers': 'Content-Type',
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST'
},
'body': json.dumps({'message':'Unexpected error'})
}
Добавьте некоторые инструкции журнала в свой lambda и проверьте конфигурацию шлюза api для настройки прокси-сервера Lambda.
Убедитесь, что вы проверили журналы шлюза api и журналы функций lambda для получения дополнительной информации об ошибке.
«Термин API появился задолго до появления Всемирной паутины. Совсем недавно появился новый термин: API-шлюз. Поначалу это звучит немного странно, поскольку концепция API сама по себе уже предполагает наличие шлюза».
Определение: Что такое «API-шлюз»?
Я очень рад, что вы спросили! Возможно, вы помните, что термин API появился задолго до появления Всемирной паутины, и вы, надеюсь, знаете, что API означает «интерфейс прикладного программирования».
Но совсем недавно появился новый термин: «API-шлюз». Поначалу он звучит немного странно, поскольку концепция API сама по себе уже предполагает наличие шлюза. Это может заставить вас задаться вопросом: «Что такое API-шлюз?».
В двух словах, API-шлюз — это инструмент управления, который находится между клиентом и набором внутренних сервисовКаждый из них имеет свой собственный API.
Поэтому шлюз API действует как единая точка входа для определенной группы API. Клиентом в этом случае обычно является приложение конечного пользователя.
С более технической точки зрения, API-шлюз можно рассматривать как специализированный обратный прокси-сервер, который может заставить различные API выглядеть так, как будто они являются одним API.
Взгляд на микросервисы
Термин «API-шлюз» часто используется в контексте микросервисов. Гранулярность API, предоставляемых микросервисами, часто отличается от необходимой. Это просто вытекает из концепции микросервисов: есть несколько маленьких частей, выполняющих маленькие разные задачи.
Микросервисы обычно предоставляют мелкозернистые API, что означает, что клиентам необходимо взаимодействовать с несколькими сервисами. Например, клиенту, которому нужна подробная информация о продукте, может потребоваться получить данные из множества сервисов. Именно поэтому в мире микросервисов имеет смысл использовать API-шлюз.
В этом контексте и в рамках архитектуры микросервисов, опять же цель API-шлюза — предоставить единую точку входа для всех клиентовно в данном случае это делается в основном за счет упрощения API, предоставляемого клиентам.
Архитектура API-шлюза
На этой диаграмме вы можете увидеть API-шлюз находится на границе систем. Он действует как инструмент управления или промежуточное программное обеспечение, которое посредничает между клиентом и набором внутренних служб.
Эти внутренние службы могут меняться местоположение, архитектуру и реализацию (язык, фреймворк и другие) с минимальным воздействием.
Архитектурный взгляд
Вам не обязательно ограничиваться представлением API-шлюза микросервисов, хотя это то, что можно назвать «классическим представлением API-шлюза».
Вы также можете взглянуть на API-шлюз с более архитектурной точки зрения и рассматривать его как шаблон проектирования. Можно сказать, что шаблон шлюза API является двойным, поскольку он фактически соответствует два классических шаблона проектирования Gang of Four: адаптер и фасад.
Как адаптерОна позволяет общаться и сотрудничать, даже если интерфейсы несовместимы.
Как фасадAPI-шлюз инкапсулирует внутреннюю архитектуру приложения и предоставляет API своим клиентам.
Как с точки зрения микросервисов, так и с точки зрения архитектуры, шлюз API всегда играет роль оркестровки и, в конце концов, должны быть там, чтобы все работало гладко. Но как перейти от концепций и определений к результатам?
Как API-шлюз может обеспечить практические результаты
Давайте погрузимся в более практические аспекты и посмотрим, как можно добиться результатов.
Для этого мы будем использовать определенный API-шлюз, наш собственный интеграционный шлюз под названием Connect Bridge. Представьте Connect Bridge как единую точку входа, которая «говорит» на SQL. Это означает, что какой бы код не использовался (а вы можете использовать любой язык программирования), он будет взаимодействовать с этим API-шлюзом, как если бы это была база данных, с помощью обычных CRUD-запросов: SELECT, INSERT, UPDATE, DELETE.
Connect Bridge имеет «переводчик» (который мы на самом деле называем «коннектор») для каждого приложения, с которым мы хотим связаться через API. Этот коннектор эффективно переводит SQL-запросы в вызовы API.
Используя Connect Bridge, вам потребуется меньше кода (намного меньше — сокращение может достигать 90% в зависимости от проекта), код будет легче понять и протестировать, и вы значительно сократите количество ошибок.
Забавно то, что когда вы работаете с Connect Bridge, тот факт, что он использует SQL, заставит вас думать, что вы работаете с базой данных целевой системы, например, с базой данных Microsoft Exchange. Но не волнуйтесь, это не так, и целостность базы данных в безопасности — это шлюз, и он всегда обращается к целевой системе через свой API.
Пошаговая работа с Connect Bridge в качестве шлюза API
- Код вашего нового или старого приложения
- CRUD-заявления на стандартном SQL с доступом к целевой системе как к базе данных
- Connect Bridge переводит SQL в вызовы API
- Для каждой целевой системы эти переводы фактически обрабатываются коннектором
Какие языки программирования я могу использовать?
Примечание о том, какой язык программирования можно использовать с Connect Bridge. Как я уже говорил, вы можете использовать практически любой язык программирования.
Вам просто нужно убедиться, что он поддерживает ODBC, JDBCили Веб-сервисы. Если это так, то все в порядке.
Например, предположим, вы хотите использовать Java. Отлично, тогда вы можете сгенерировать строку подключения JDBC, и вот у вас есть шлюз Java API.
Вы хотите использовать Node.js? Это тоже хорошо, вы можете сгенерировать строку подключения к веб-сервисам, и у вас будет API-шлюз Node.js.
Я мог бы продолжить, но, думаю, вы уже поняли: вы можете продолжать и использовать свой любимый язык программирования.
Соединительные струны Connect Bridge
Ценообразование API-шлюза Connect Bridge
Connect Bridge является платным инструментом, цены варьируются в зависимости от количества и типа используемых коннекторов и количества пользователей. Чтобы вы имели общее представление о стоимости этого API-шлюза, мы можем сказать, что цены начинаются от 150 евро в месяц. Для получения более подробной информации о ценах перейдите здесь. Мы рекомендуем попробовать самостоятельно с бесплатная пробная версия сначала, и таким образом вы сможете получить представление о том, каким будет прирост производительности.
С точки зрения окупаемости инвестиций, вы также должны учитывать, что шлюз обеспечивает окончательное решение продолжает работать даже при обновлении целевой системы без каких-либо изменений в написанном вами коде. Все хлопоты возьмет на себя шлюз.
Первые шаги с Connect Bridge
Чтобы провести вас через первые шаги работы с Connect Bridge, нам понадобится пример целевой системы. Мы выберем для этого Microsoft SharePoint, но это могут быть и другие системы.
- Запросить бесплатная пробная версия.
- Установите Connect Bridge.
- Выполните конфигурацию с помощью Connect Bridge Management Studio:
- Аутентификация шлюза API состоит из двух этапов. Чтобы подключиться к SharePoint, пользователям необходимо подключиться к Connect Bridge, а затем Connect Bridge необходимо подключить к SharePoint.
- Добавьте учетную запись для SharePoint (Учетные записи — Добавить учетную запись). Вам понадобятся ваши учетные данные SharePoint.
- Либо разрешите пользователю Administrator по умолчанию использовать эту учетную запись, либо создайте нового пользователя и разрешите ему использовать учетную запись SharePoint.
- o Нажмите на опцию New Query (Новый запрос), а затем на Connection Browser (Браузер подключений). Найдите коннектор SharePoint и открывайте его, пока не дойдете до DefaultConnection. Щелкните на нем правой кнопкой мыши и выберите Get Connection string. Затем скопируйте соответствующую строку подключения. Она понадобится вам для вашего кода.
- Аутентификация шлюза API состоит из двух этапов. Чтобы подключиться к SharePoint, пользователям необходимо подключиться к Connect Bridge, а затем Connect Bridge необходимо подключить к SharePoint.
Испытание Connect Bridge
Используйте опцию Новый запрос, чтобы проверить запрос, который получит нужные вам данные из SharePoint. Здесь мы рассмотрим пример запроса, однако его следует скорректировать в соответствии с тем, что вы хотите получить от SharePoint.
Выбрав опцию New Query (Новый запрос), откройте Connection Browser (Браузер соединений).
- Найдите коннектор SharePoint и откройте его, пока не увидите опцию Tables. Вы сможете увидеть, что схема содержит «таблицу» под названием Site_Pages.
- Мы можем использовать запрос SELECT UniqueId, ContentType, Created, Modified, ContentVersion FROM Site_Pages LIMIT 10;
Это позволит выбрать первые 10 записей из списка «Страницы сайта» SharePoint.
Обратите внимание, что хотя кажется, что мы используем базу данных напрямую, это совсем не так. Connect Bridge обращается только к API, а затем представляет данные так, как будто они получены из базы данных. Не стесняйтесь исследовать здесь немного. Вы также можете изучить доступные хранимые процедуры. Как только вы составите запрос, скопируйте его, потому что он понадобится вам в вашем коде.
Также важно отметить, что на данном этапе вы просто тестируете. Вы можете рассматривать Connect Bridge Management Studio как игровую площадку. Когда вы будете удовлетворены полученным запросом, вы просто используете его в своем коде, как если бы вы обращались к базе данных. Это довольно просто.
Для получения более подробной информации вы можете ознакомиться с документацией по шлюзу API, которую вы получите при получении вашего бесплатная пробная версия. Вы также можете проверить журналы шлюза API, что в Connect Bridge легко сделать с помощью функции Connect Bridge Студия управления используя опцию Центр администрирования — Система — Журналы на панели навигации.
Заключение и выводы
Концепция API-шлюза может показаться поначалу слишком теоретической, однако, если сосредоточиться на конкретном инструменте, таком как Connect Bridge, нетрудно представить себе его преимущества.
- Доступ осуществляется централизованно на шлюзе API, независимо от количества целевых систем
- Отсутствие необходимости изучать новый API или язык программирования позволяет сократить количество ошибок и повысить производительность труда
- Обслуживание также централизовано и изолировано — все это происходит на стороне API-шлюза, а не в вашем коде, при этом Connect Bridge гарантирует прямую совместимость для каждой целевой системы (а также обратную совместимость, если она вам когда-нибудь понадобится).
Если у вас есть какие-либо комментарии или предложения, напишите их в форме ниже, и мы ответим как можно скорее.
Вопрос
[решена]
Новый с AWS (и StackOverflow). Я пытаюсь создать службу лямда на AWS и его доступ извне через шлюз API с без проверки подлинности или требуется ограничение.
Чтобы сделать вещи легко я настроить шлюз для теперь будет издеваться.
Получить метод API-интерфейса, авторизации установлен в None и ключ API не требуется`.
Когда я пытаюсь это, я получаю {"Мои сообщения и": на"запрещено" и}
(такое же сообщение, если я подключить его к фактической службы лямбда).
Любые советы о том, как сделать его доступным?
Спасибо
Ответ на вопрос
21-го апреля 2017 в 4:17
2017-04-21T04:17:09+00:00
#32260440
Если вы установите ‘API-ключ требует’ опции true, то, пожалуйста, проверьте ниже.
- вы должны пройти ‘х-API-ключа’ параметр заголовка HTTP к API шлюза.
- API-ключ должен быть создан.
- Кроме того, необходимо проверить План использования API-ключ на консоли API шлюза.
Ответ на вопрос
7-го июля 2017 в 8:28
2017-07-07T20:28:40+00:00
#32260441
На шлюз с API панели выбрать ресурсы, нажмите кнопку действия и выберите команду развернуть АПИ. До первого развертывания единственный ответ, который вы’ll получить это {"Мои сообщения и": на"запрещено" и}.
Ответ на вопрос
10-го февраля 2018 в 5:40
2018-02-10T17:40:57+00:00
#32260444
Если вы используете собственное доменное имя и забыть, чтобы выбрать пункт назначения промежуточные, вы’МР получить «запретный» сообщение.
Просто зайдите в пользовательские доменные имена и нажмите кнопку «Редактировать» под вашим доменом, а затем выберите сцену под базы сопоставления пути`.
Ответ на вопрос
28-го декабря 2018 в 9:45
2018-12-28T21:45:18+00:00
#32260450
Вы должны развернуть свой API на этапе и этапе использовать URL-адрес перейти к ресурсам, нажмите кнопку действия и выберите команду развернуть АПИ
Теперь, если вы получаете сообщение об ошибке
{«Мои сообщения и»: на»запрещено» и}.
Пожалуйста, проверьте следующие шаги
1 ) Если Включить API ключ скопировать и передать свой ключ в почтальона
- Теперь вы по-прежнему получать же ошибка означает, что вы должны создать план использования
- установить лимит и назначить план для вашего API
Ответ на вопрос
4-го февраля 2018 в 2:08
2018-02-04T14:08:50+00:00
#32260443
У меня была похожая проблема, и я имел следующее:
- Пользовательский Домен (Края Оптимизирован)
- В несколько этапов (разработки, промежуточная прод)
Также Я’т установить любое разрешение, ни ограничений, чтобы сделать вещи простыми.
Я был в состоянии исправить проблему путем добавления базы сопоставления путь для каждого из этапов (разработки, постановка, прод).
Ответ на вопрос
29-го июня 2018 в 12:01
2018-06-29T12:01:16+00:00
#32260445
Если вы установите ‘АПИ’ ключ необходимо верно, нужно сдать API-ключ в качестве заголовка.
API-ключ передается как поле заголовка ‘х-API-ключа’. Даже после добавления этого поля в заголовке, это может произойти. В этом случае, пожалуйста, проверьте ниже пунктов
- Есть ли у вас план использования? если не нужно, чтобы создать одну.
- Ссылку API с Плана использования. Для этого добавьте в сцену, он свяжет свой API.
- У вас есть ключ API? если не нужно создать API-ключ и включить его.
- Добавить в План использования, который связан с вашим API для этого API-ключ. Для этого добавьте Плана использования.
Ответ на вопрос
20-го ноября 2018 в 12:38
2018-11-20T12:38:47+00:00
#32260449
Это может быть далеко не очевидно, но еще одна причина увидеть, что «запрещено» и ошибки при использовании шлюза в AWS API может быть назвав неправильный URL-адрес, который не соответствует ни развернутого метода API. Это может произойти, если вы’вновь действительно наезд неправильный URL-адрес (например, вместо вызова https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/users (ПримечаниеДэвэтап перед "пользователями") вы назвалиhttps://9999xx9x99.execute-api.us-east-1.amazonaws.com/users` (не этапа). Вы’d не ожидал получить 404, но вы’ll получают 403.
Кстати: после развертывания в https://9999xx9x99.execute-api.us-east-1.amazonaws.com/dev/users призвание `https://9999xx9x99.execute-api.us-east-1.amazonaws.com/user (Примечание здесь существительное форма) вы’ll получить… 403, но с «отсутствует маркер проверки подлинности» и сообщение!
Ответ на вопрос
2-го октября 2017 в 3:47
2017-10-02T15:47:52+00:00
#32260442
Если авторизация и API-ключа требуется-оба имеют значение true для этого метода, то убедитесь, что у вас есть следующие заголовки при отправке запроса:
- Контент-тип (обычно применение/х-www-формы-urlencoded, если вам звонят)
- Хозяин
- Х-АМЗ-Дата
- Авторизации
- х-API-ключ
Я использую почтальон для тестирования API, который является довольно надежным и потом он’ы довольно прямо вперед.
Примечание: не добавить X-API-ключа заголовка, если у вас есть набор ключевых API, необходимую в качестве ложного.
И если у вас есть набор «авторизация», как ложно тогда не добавить заголовок авторизации.
Ответ на вопрос
14-го ноября 2018 в 7:51
2018-11-14T19:51:54+00:00
#32260448
Я может быть слишком поздно, но одна из причин шлюз API даст, что «запрещено» и сообщение, когда вы передаете данные в теле запроса на операцию. Чтобы решить проблему либо сделать ваш пост-ресурса или вы не передаете данные в теле запроса.
Ответ на вопрос
27-го марта 2019 в 5:08
2019-03-27T17:08:23+00:00
#32260454
Я мог бы встретить решение этой проблемы.
У меня была такая же проблема сейчас на macOS.
Я пытался потопите мой DNS а потом она работала!
Попробуйте это в терминале:
Mac ОС X Yosemite и позже
Мак ОС Х Йосемити В10.10 через В10.10.3
Мак ОС Х Маверикс, горный лев и Лев
Мак ОС Х Снежный Барс
Ответ на вопрос
9-го октября 2018 в 6:56
2018-10-09T18:56:28+00:00
#32260446
Я получил эту ошибку от nginx и услуги fargate пытаются получить доступ к собственным API в API шлюза. Мне нужно добавить политику в соответствии с политикой ресурса на мой API, таких как этот
Ответ на вопрос
1-го марта 2019 в 8:46
2019-03-01T08:46:03+00:00
#32260452
Есть несколько вещей, чтобы сделать, когда мы получим {сообщение: запрещено} в шлюз по API:
ПДБС включен?
- Проверьте, если включен CORS в пределах API ( для начала, разрешить происхождения ‘*’, чтобы убедиться, что мы можем спокойно проверить )
- Развернуть API, чтобы убедиться, что все настройки как положено
API-ключ включен?
- Проверьте, если у нас есть ключ API включен в API шлюза
- Проверьте, если есть API-ключ настроен.
- Проверьте, если ваш ключ API назначается правильное usageplan и добавить этап API, то без этапа API, вы всегда получите {сообщение: запрещено}
Если вы все еще возникают проблемы, дайте мне знать, чтобы я или один из наших облачных гуру @levarne может помочь.
Ответ на вопрос
25-го января 2019 в 4:36
2019-01-25T16:36:56+00:00
#32260451
Локальный Брандмауэр / антивирус или NGIPS (компания Cisco оживленном). Последнее было мое дело, где я не’т даже сделать логи в CloudWatch из моих API. Это позволяет моим доменом верхнего уровня, размещенных сайте, но и блокировало с 403 в АПИ поддомен, без тела в браузере’вкладка сети с Дев-инструменты.
Ответ на вопрос
25-го октября 2018 в 6:26
2018-10-25T06:26:51+00:00
#32260447
Мы столкнулись с этой проблемой в наше производство, когда мы использовали Гонконг как шлюз по API. Наши просьбы прошло беспересадочный, когда инициированный почтальон, но не с 403 при запуске через код. Плагин бот в Гонконг был включен которые разрешен только запросы, инициированные из браузера или мобильного приложения на основе заголовка агента пользователя значение.Наш запросов, инициированных через HTTP-клиента не удалось. Как только мы отключили бот плагин тут не об ошибках. Это теперь позволяет запрос, если пользователь-агент является Apache-HttpClient, который/4.5.2 (Ява/1.8.0_91).
Ответ на вопрос
13-го марта 2019 в 7:41
2019-03-13T07:41:45+00:00
#32260453
Я получил {с"сообщения и": на"запрещено" и} на API с EndpointConfiguration «личный», и VpcEndpoint в СИЗ’ы частные подсети (это Интер-сервис API)
Почему я получил {с"сообщения и": на"запрещено" и}, что я был под впечатлением, я должен использовать один из VpcEndpoint’с URL-адреса. Url, чтобы использовать еще один связанный с этапом (в консоли ApiGateway). Это:
с https://${RestApiId}.выполнить-интерфейс API.${Региона}.amazonaws.com/${сценический псевдоним}
Созданная функция Lambda Hello world с использованием Node.js и созданный триггер API GateWay для вызова Get, попробовал URL-адрес для доступа к функции Lambda, получив ниже ошибки.
сообщение: «Внутренняя ошибка сервера».
(очень новый для AWS)
Ответ 1
Вам необходимо передать statusCode после выполнения функции Lambda. Если вы его не пройдете, API 502 Bad Gateway по умолчанию вызовет ошибку 502 Bad Gateway.
message = {
'message': 'Execution started successfully!'
}
return {
'statusCode': 200,
'headers': {'Content-Type': 'application/json'},
'body': json.dumps(message)
}
EDIT: этот образец предназначен для Python. Для node.js вам просто нужно обработать обратный вызов, сообщение в основном то же самое.
callback(null, {
statusCode: 200,
body: JSON.stringify(message),
headers: {'Content-Type': 'application/json'}
});
Ответ 2
Не забудьте развернуть API под AWS API Gateway. Без этого изменение не работает.
Ответ 3
У меня была эта проблема, но в моем случае я использовал API Gateway и java лямбда-функцию. Когда вы смотрели в cloudwatch, ошибок не было, все выглядело отлично. Проблема возникает, когда API-шлюз пытается отобразить ответ. В моем случае, у меня в объекте ответа, statusCode, который не был int, в то время как шлюз API должен быть int.
это
private final ResponseCode statusCode;
private final String body;
private final Map<String, String> headers;
private final boolean isBase64Encoded;
После того, как я изменил statusCode на int
private final int statusCode;
Это работает
Ответ 4
Эта ошибка указывает на то, что возникла проблема с конфигурацией API. Если вы включите журналы CloudWatch, вы можете увидеть дополнительную информацию: https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cloudwatch-logs/
Ответ 5
У меня возникла проблема с использованием API Gateway + Lambda. В моем случае проблема была просто проблемой разрешения. Я использовал этапы своего API.
Мне пришлось выполнить
aws lambda add-permission --function-name X --source-arn "X" --principal apigateway.amazonaws.com --statement-id X --action lambda:InvokeFunction
Надеюсь это поможет.
Ответ 6
Это уже объяснялось выше, но моя проблема заключалась в том, что это сработало для меня, просто вызвав лямбду:
exports.handler = async (event) => {
return "gugus"
};
Так что все тесты в лямбде были в порядке. Бревна тоже выглядели хорошо. Просто ответ API был не в порядке.
Чтобы вызвать его с помощью шлюза API, нужно что-то вроде этого:
exports.handler = async (event) => {
...
var res ={
"statusCode": 200,
"headers": {
"Content-Type": "*/*"
}
};
res.body = "gugus";
return res;
};
Ответ 7
Обязательно передайте тело в виде строки в ответе. Если это объект, он потерпит неудачу и выдаст вам ошибку, которую вы видите. Смотрите здесь для получения дополнительной информации — http://www.awslessons.com/2017/lambda-api-gateway-internal-server-error/