I'm having some trouble determining the difference between Routing on a traditional web programming framework and API gateway. Let's say if I setup a Laravel web app and define routes in it as follows:
Route: GET `/area' -> Returns all hotels in a specific area
Route: GET '/hotel' -> Returns details of a specific hotel with ID
Route: POST '/hotel' -> Accepts JSON object (with Hotel details) and creates the hotel in my database
So basically, I have one API and three HTTP endpoints. Since this is defined in my programming language for my web app, why would I need an API gateway? What is the difference between defining routes in my programming language and creating routes on the API gateway? Are API gateways only used for serverless architectures?
Since my API won't be accessed by any other website, is an API key even necessary?
I tried creating routes in a serverless architecture and using Lambdas to resolve my APIs but I'm finding it difficult to understand why/when an API gateway becomes relevant.
Related
Am I able to define a pre-generated api gateway url for my serverless application?
Currently there are two applications already made that has their own that was generated with cloud formation. The new application is using the serverless framework.
The client asked that I reuse the one that was generated for the other two applications on mine to extend the amount of endpoints over having its own url.
It’s not a custom url that uses a cname just a straight generated api gateway one they would like me to piggy back off of.
Sadly you can't do that with AWS-provided URLs. The only way to join several APIs under a single URL domain is to use custom domains. Then you can hook up multiple APIs to one domain, e.g. api.mydomain.org, api2.mydomain.org.
Or to put it another way:
Should I consider my list API routes public?
Reason for asking is if I setup a web hook for a payment service - will this be available to anyone to post to?
I guess the thing to do would be restrict to their origin.
Is it that Cloud Endpoints enable the implementation of a REST API?
It looks like it is possible to create a REST API by just using Flask to handle different methods (GET, POST, PUT, etc.), so where exactly does Cloud Endpoints meet REST API?
Or, perhaps it is that Cloud Endpoints lets you create your own API service that can be consumed by many apps by providing them their own client ID + client secret?
I am trying to demystify what exactly is scope of usage of Cloud Endpoints.
Cloud endpoint is an esp which means that is a proxy between your APIs (rest or grpc) and the rest of the world.
This endpoint allows you to expose a clean interface and the underlayer implementation can be the mess. You can define endpoints and route query to different implementation: functions, VM, cloud run, app engine,.... And even on other cloud!
You can manage authentications (especially API keys), rate limit, logging, tracing,...
And you can transform a query to another one (change param name, add Decatur default values,...)
It's very powerful and based on open API (swagger).
For example, it allows you to expose a service and to migrate it piece by piece transparently.
The best level is apigee but it's expensive!!
This is the first time I use AWS Lambda as an API architecture.
Because im trying to implement serverless.
Let say, I have three microservices where all of the microservices hosted on AWS Lambda.
And I use AWS API Gateway as router. I also implemented Jason web token in API Gateway.
This is the public URL that the frontend will use.
URL Routing API - https://mydomain.co/v1/lambda-service1
Lambda REAL URL - https://cr7z0dds42.execute-api.ap-southeast-amazonaws.com/DEV/
URL Routing API - http://mydomain.co/v1/lambda-service2
Lambda REAL URL - https://cr7z0ddgg2.execute-api.ap-southeast-amazonaws.com/DEV/
API Routing URL - http://mydomain.co/v1/lambda-service3
Lambda REAL URL - https://cgf7z0ddgg2.execute-api.ap-southeast-amazonaws.com/DEV/
Basically, if I am currently my client / frontend, I want to call data from API number 1 by using TOKEN, i will use the API routing URL.
But there are some cases that the API number 1 needs to call service number 2 before return to client / frontend.
Currently what I do is call directly service number 2 via Lambda REAL URL, not API Routing URL from service number 1 without using TOKEN.
Is this justified?
If I got your query correctly maybe below might assist.
Justification is mainly based on the scale you expect the app you are developing and also your organisation/architecture policies (you might want to enforce).
If tokens are used for all API calls and making it consistence will make it easy when a wider team of developers working on the project down the track. Also make it easy for troubleshooting, as the scope of each Lambda function (in/outs) logic is clear and consistent.
Also another thought is around cost, API calls does cost you at scale. So that should be taken in to consideration as well during architecture. But (in my opinion) consistency in the app call flow, for the savings it might give for traffic not hitting API gateway, where the call is made directly from Lambda to internal resources might be negligible.
Anyways some thoughts to consider.
In our previous regular instance-based backends, for a pretty good portion of the development process of the API, we were protecting the dev version of the endpoints with basic auth.
Is there a pattern of how to efficiently hide our serverless endpoints (API Gateway) from public, but still available for the frontend team to develop on?
Create an API key for your non-production API Gateway. A different key from any that you use in production. Give that key to your dev team, then they will be able to call your non-production API Gateway endpoints, while the API will be inaccessible to anyone without the key.