Usage Plans for AWS API Gateway
aws.amazon.comI wish they'd focus on speed and rebuilding API Gateway to be easier to use, or provided a new proxy option to run Lambda under. This set of changes doesn't seem to improve on any of the practical issues in using Lambda with API Gateway.
I wish they'd focus on implementing basic HTTP support.
* you can't serve non-UTF8 content
* HEAD is totally broken (you can't set Content-Length)
* custom authorizers are useless with 3rd-party clients since you can't set WWW-Authenticate
* 100 Continue is blindly sent before checking auth
And then if they could get around to writing an actual reference document rather than the rambling stream-of-consciousness narratives they have currently, then maybe I'll be able to learn what the heck an "Integration Request" is and what syntax custom authorizers are supposed to return.
I agree, especially regarding the documentation. I was trying not to be too negative, but using Lambda is an exercise in frustration because of API Gateway.
I hope they hook up the new ALB service as an option for a Lambda proxy.
Personally I wouldn't care so much if they called it "AWS Gateway Beta" or something. That its limitations aren't advertised, leading me to waste time trying to figure out what I was doing "wrong", is what frustrates me.
I use a custom authorizer with Auth0 and it works fine. I guess some systems still use Basic Auth though.
WWW-Authenticate is a requirement of HTTP itself, not Basic Auth. Returning 401 without this header (which API Gateway does) violates RFC 7235. It is the means by which HTTP negotiates an authentication protocol; without it, there is no way for authentication to proceed except by guessing.
Latency was a concern at launch but it has improved a lot, I see less than 20 ms these days. Depends on scale though, we have moderate sustained load 24/7
API Gateway was a pain to use when it first came out. The API wasn't supported by AWS CLI and there were no good wrappers for it in Node.js (my preferred language for APIs).
Has the situation improved?
API Gateway is supported from the cli: http://docs.aws.amazon.com/cli/latest/reference/apigateway/
and is part of the SDK for Node: https://aws.amazon.com/sdk-for-node-js/
I would suggest checking out https://claudiajs.com/. I used it for a few quick API Gateway to Lambda things and it seems to be pretty sweet so far.
So this is why our API had a rash of 500 errors last night. We haven't been very happy with the uptime of this service, mostly because they do deploys that break things for a couple minutes about once a month.
Do you use Lambda as a backend? If so, this might have been related to Lambda, not the API Gateway. I also saw a number of 500s, but upon further digging, the API Gateway was fine, but the Lambda functions it was invoking were returning "Service Error." Still not happy either way, but I've generally been impressed with the gateway product itself.
Lambda was having capacity issues last night in us-east-1.
I run a monitoring service so I'm obviously digging for info here, but I'm genuinely curious: what do you use for monitoring?
Not the OP, but we use CloudWatch for these kinds of things. Very easy to just say "send me an email if API Gateway 500 errors exceed 5 in 1 minute"
But what can you do if locked into AWS?
Everyone acts like being locked into a provider is the worst thing that could happen. When it comes to monitoring, if I'm using other AWS products, I don't mind being locked into AWS monitoring as well. Because I'm either going to just use it and be done with it, or I'm going to spend months and lots more money finding a non-AWS solution that integrates as well with AWS. If we ever switch away from AWS, I'll invest the time then to use a new product, but until then, we accept the trade-off for saving lots of time and money.
Yes, I was getting 500s due to Lambda connectivity issues with my authorizers last night.
I like the service and I use it for mock endpoints and other non-production applications, but I never managed to make gzip compression work in API Gateway. Actually, it seems to me that even when the origin serves gzipped content, it comes out uncompressed from API Gateway. Clearly a no-go for mobile apps. Anyone had the same experience, or did I miss something obiouvs?
API Gateway can't serve binary content, making it useless for anything but JSON toys.
I don't see the value in compressing small payloads less than 1K. Plenty of APIs serve small, structured content.
And plenty need to serve non-UTF8 data, such as images, or documents with a content encoding (like the GP was trying to). Sure, "JSON toys" is a bit hyperbolic, but "HTTP service that can transfer media" describes some double-digit percentage of all web services. API Gateway may fully support many use cases, but in my mind it's a toy until it supports this major one.
(Note that it's not like API Gateway claims up front "JSON only!" or some such. Outbound binary data just silently gets garbled and the only mention of this limitation is buried in various threads on the forums.)
It amazes me it took them long to get here.
Six months I was looking around and found that API gateways from various vendors addressed everything somebody might want in an API gateway except the one thing you need for a minimal viable product -- a way to charge for API calls.