Day One with the Amazon API Gateway

Thanks for a clear, sensible investigation. ISTM your auth complaint is well-taken. Either Lambda should be seeing the same role as the gateway automatically, or there ought to be a way to configure that.

However, I have to admit that my first reaction to that difficulty in getting the account ID from the path/query/etc would have been to just shove it in the request body JSON that was already coming through. Then it could probably be taken out of the path completely, which would be a win for url privacy at least. This doesn't seem like the showstopper that the auth issue does.

Amen.

Last Sunday morning, I was so excited to move my APIs over to AWS’s API Gateway. That evening, I was ready to kill.

I spent the entire day (9+ hrs) getting merely two API routes working. A GET and a dreaded POST request.

I couldn’t tell from your post if you eventually figured it out, but it is possible to get the POST request body and url params in your Lambda event as JSON.

In my POST Method’s Integration Request, here’s how I get the query string parameter and the request body. I use this Input Mapping.

#set($inputRoot = $input.path('$')) { "access_token":"$input.params('access_token')", "name" : "$inputRoot.name", “email” : "$inputRoot.email” }

A “glass half full” way to think about all of this is that the AWS API Gateway is ridiculously strict about what data can be passed in to your Lambda functions, and you must explicitly state that data.

Here are other problems I ran into over the weekend:

- The web console is super buggy with broken links and really, really bad UX.

- The documentation is missing for many essential components.

- No support for API Gateway in the AWS SDKs

- I can't figure out how to copy resource methods, so I have to do tons of redundant manual input when creating each resource method, which includes explicitly stating every HTTP Error response code.

- Returning error objects from Lambda functions also needs mapping.

- Out-of-the-box slow response times. My Lambda function with two simple DynamoDB queries often takes 3 seconds to return a result when its route is hit.

Overall, I'm a huge AWS fanboy but the execution of this product is incomplete and out of touch.

C'mon AWS, you can pull through on this. Keep it simple. Build out from there. We all want you to succeed.

Good write-up, interesting find about the lacking features. My take on the API Gateway - https://medium.com/@john.titus/moving-a-simple-api-to-amazon...

I spent some time reviewing this post with the API Gateway team here at Amazon! Here's what I learned:

1. We are updating the documentation in response to the feedback in this thread and in the blog post. Additional feedback is always welcome.

2. Based on the feedback in the blog post, mappings can now access the JSON body of a POST. See the answer (login required) at https://forums.aws.amazon.com/thread.jspa?messageID=645596&#... .

3. Models are not required for validation. They are simply used to generate the objects in the client SDKs.

I spend some time with API Gateway this weekend. Since I work at a company that has a product that helps customers with authentication and authorization for APIs, I am always curious where everyone else is skating.

Your section about authentication resounds with me loud and clear, I couldn't hack it out in 6 hours. This will be a pain point for anyone using API Gateway for anything other than a toy API.

Having the possibility to create an HTTP RESTful interface to many Lambda functions running on AWS is the biggest advantage of the AWS API Gateway.

Technically, stretching the system a bit, one could argue that we don't need backend software running on EC2 anymore, since everything can be a Lambda function with an associated HTTP endpoint to trigger it. I have been thinking about this a lot, and it could work if being locked into AWS is considered an acceptable risk.

For anything else more API-oriented (more authentication schemes, better security, more logging options, etc) I would suggest checking out Kong (https://github.com/Mashape/kong), which is pluggable with extra functionality and can work in front of the AWS API Gateway to enhance the REST-to-Lambda interface (and with any other API).

My take after trying this out for a few hours mirrors yours: it looks like it was rushed out the door and not 100% ready. It's fun to play around with, but I wouldn't put anything production on it for at least another few months.

The other thing that is terrible is versioning. Lambda does not support versioning. And the resources/methods that you define for your various stages all share the same resources/methods, unless you want to change the signature of your calls. So if I want to change an existing Lambda function, then the minute I change it for my staging/test/qa environment, I have changed it for production as well. So, I can't roll back easily. I can script all this, but ouch. The alternative is to create a whole new API gateway, but that means that once I get my stuff tested, I essentially have to recreate my new environment in production, insteading of just clicking a button.

We have a client who is looking at sending a massive amount of data to a REST API. Looks like we are going back to Elastic Beanstalk, which is pretty good, it just has servers. But it works.

And, I'd say that using Dyanamo as a DB locks you much more securely into AWS than API Gateway and Lambda. Be pretty easy to take those Lambda functions and map them back into Express or Restify routes. Changing the database, arg.

I've started messing with API Gateway and Lambda there a couple errors.

If you create a lambda function and add a gateway inside the lambda function configuration screen, it will give you a bad API gateway URL. Going into the API gateway page and looking at your stages URL and trying that works.

This just proves that it was rushed out. I do like the idea though and want to use it, but I don't think it'll be ready until Q4.

> Out-of-the-box slow response times. My Lambda function with two simple DynamoDB queries often takes 3 seconds to return a result when its route is hit.

This is something I've also noticed. Even their official examples are really slow [0]

About auth: I've been researching API Gateway + Lambda and auth via Amazon Cognito. As of now the best example for auth I've found is LambdAuth [1]. I'm trying to add the API Gateway in the mix, it looks possible to integrate it.

I also agree that docs and more explicit examples are needed.

[0] https://aws.amazon.com/blogs/compute/the-squirrelbin-archite...

[1] https://github.com/danilop/LambdAuth

Just a quick nitpick: the second link in the article (the one to AWS Lambda) should have an all-lowercase URL; the URL's case-sensitive and - in its current capitalized form - is resulting in a 404.

I'd come across the same issues you are experiencing and had been looking for a solution to the $input.path() issue.

Turns out to retrieve JSON you can use $input.json().

Full details are on the AWS documentation page. Not sure if this has been newly added as I only found it today.

http://docs.aws.amazon.com/apigateway/latest/developerguide/...

The feature-set for this is pretty low. I've built a better solution with much more raw access to HTTP request and response streams.

If anyone is interested in an open-source version of Amazon API / Amazon Lamba, you can check out: http://github.com/bigcompany/hook.io http://hook.io

I've experienced the same frustrations with the API Gateway. Lack of knowing the IAM principal that authenticated, and no clear way to differentiate if a call came from the API gateway or not makes me feel that this needs some work. SNS, for example, will sign it's HTTP requests and that would be a good start IMHO. Ability to use security groups in proxy mode would make this even better.

My major use case is a read only, throttled, and cached front end for the mediawiki api at http://snpedia.com . The ability to monetize the api for higher throughput is an appealing plus. Gateway still seems pretty good for this. I'd welcome input or thoughts from others.

thanks for your sacrifice in investigating this. I will return in 2016 when hopefully this is production-ready

Isn't lambda suicide for a startup? Think of all the lock-in here. If you go big you could suddenly find yourself really stuck if you're overly dependent on it and the overhead of lambda/gateway is too much.