As far as I understand, there are only three ways to access AWS resources:
Management Console (browser)
AWS CLI
AWS SDK (in various programming languages)
However, why did not AWS provide REST APIs and their reference document so that we can interact with AWS resources directly using a REST client like Postman?
I think they are using REST APIs behind the scenes (All the above three interactions actively use REST API I guess).
Thanks in advance.
There is REST API documentation available as well. Its just that AWS officially encourages the use of more abstract methods such as using CLI and SDK since its easier to use as well as they are maintained by AWS.
Also using the sdk or cli is encouraged because they are perfectly interfaced with the aws rest api with extensive testing and covering all cases. And you don't need to focus on stuff like what headers you need to attach or what should be the request body format. Users can focus on writing their own business logic.
The only source I could find for documentation of rest api are the official docs which I have linked below. Since the direct use of rest api is not preferred hence no commonly available tutorials. I don't think there is anything extra which can be accomplished using the rest api which the cli or sdk doesn't already offer.
A more practical example would be aws s3 cli. It has a lot of underlying implementation which speeds up the process of uploading and downloading, like establishing 10 network connections in parallel to utilize the complete network bandwidth etc. This you would have to implement yourself if you are directly using the api.
Some Examples:
S3 REST API
EC2 REST API
Similarly there is API documentation available for every service.
Related
we use Aws Api Gateway to protect our apis.
We want to create an sdk for developers. The idea is to have In app purchase in their apps and call our apis in order to start payment.
We are trying to have a way to connect machine from machine. The first machine will be an sdk integrated in Android games and the second will be our back end protected by the api gateway.
The sdk should have a the authorization to consume the api.
Today we don't know how to do it, even after discussing with many architects.
The sdk is not going to have user and password, because it is not a user, so no way to generate the classic access token.
How could we achieve this use case ?
Thanks
The sdk should have a the authorization to consume the api. Today we don't know how to do it, even after discussing with many architects.
There are three possible ways to have a protected API Gateway. AWS Cognito and AWS Lambda. The third option, API Keys, is a little bit different than the previous two.
With Cognito, you create user pools and API Gateway automatically handles authorization when a request is received.
With Lambda, you create your own custom authorization logic.
I generally prefer the Lambda approach due to the ease of use but it depends on the use-case.
With the API Key option, you create API Keys for specific routes and API Gateway checks them through the request headers. I think any use-case that requires this can be handled with the Lambda option as well.
What you are describing doesn't sound difficult to achieve.
You will generate an API key and you will give them to the developers that will use your API.
In your SDK, you can accept the API key as an initialization parameter and provide it in the requests to API Gateway.
I’m trying to pick up API gateway.
What are the different use cases for alb vs API gateway? I’ll be honest to say that I am not completely familiar with the concept of an API. I know we can invoke it backend, and the analogy that it’s a restaurant menu. However, beyond that, I am not clear what the difference is. Is it that applications using ALB has a user interface, but not API gateway? I tried reading through documentation on the features, but got even more lost. As such, I am hoping someone can share the use cases for both services so that I can visualise what it’s used for and the reason for the features. Thanks!
API GW is focused on API and has some additional options - e.g. API definition via swagger, execution of a lambda function, converting the call to an event bridge event, support of authenticators (iam, cognito), multiple deployment stages etc.
The load balancer listens on a port and that's about it.
Q: In what cases would you require these API GW features as opposed to just using an ALB?
A: One obvious benefit is a serverless or "low code". Let's say you want an API which processes asynchronous requests.
It is possible to create an API endpoint which queues all incoming requests to a SQS queue with just one AWS CLI command with no programming (provided the resources do exist):
https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services.html
Each API endpoint can be served by a different AWS resource including EC2/ALB.
ALB is well suited for things like traditional monolithic applications (LAMP, Java application servers etc.)
I'm trying to integrate Cognito Authorizers into an existing application that is using API Gateway to authorize requests.
The documentation insists on using AWS Amplify to make these calls, but I'm not sure that this fits in well with the existing architecture since Amplify seems to have its own way of making API requests, and I'm worried that it would mandate having to change all of the existing API requests...
So my question is if there are more readily integratable solutions to this problem, or if my concerns are unfounded.
There are several SDK's that can be used with Cognito.
You can use the AWS js SDK to make low level API calls but you will lose the benefits that the Cognito Client Side SDKS provide like session management, caching of tokens and SRP calculations.
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.html
You can also use the Cognito Identity SDK which Amplify uses under the hood:
https://www.npmjs.com/package/amazon-cognito-identity-js
The Auth SDK if you are going to be integrating with the OAuth endpoints, which is now deprecated but can still be used or referenced, Amplify also uses or has similar functionality.
https://github.com/amazon-archives/amazon-cognito-auth-js
And then finally Amplify which is the go to, feature rich client side SDK which for the majority of usecases should be the SDK of choice in my opinion.
I'm searching for a possible solutions on how to control versioning of an API. Currently I have a non-versioned API using ASP.Net Core on a EC2 machine on AWS and I need to maintaing multiple versions of it simultaneously. I heard of a few options like:
Different Docker containers for each version.
A diferent proxy for each EC2 machine containing different versions.
Controller Versioning different end-points for each version.
AWS Api Gateway.
but I don't know much about this topics, and what is the best practices versioning and other options I have.
why not use API Gateway for this overall solution? You can use Staging to have more a version control for your API Gateway when deploying and testing. Also,
API GATEway allows you to approach API in a serverless approach and aspect.
If you want, you can use AWS Code Commit to keep track and build branches for a different version of your API.
AWS Code Commit
API Gateway
At the moment I am building various REST API's using AWS API Gateway, which is going great, but I am managing all these API's just through the WEB UI (Usual AWS Console ).
Is there a way, I can store all my API config in a source control ? So that I can keep track of the versions ? I don't want to just depend on API Gateway alone for these configurations, it will be great to have these API specifications in a source control.
Also I understand that API gateway supports swagger, that way I can store the swagger API specification somewhere. BUT I guess swagger won't cover all aspects of an API, For eg: if I am using mappings templates in API Gateway for talking to DynamoDB, how can I manage the mapping templates ?
Any thoughts ?
The question has been asked some time ago and I dont have a better answer
Hopefully, meanwhile, the serverless framework has improved a lot. It can support nodejs and python2.7 code and java should come.
serverless also supports Templates & Variables so so you can manage your dynamo resource from a Json or yaml file
Note: the aws-api-gateway already exists so feel free to use