I'm having a lot of duplicated mapping templates across endpoints on my AWS API Gateway implementation.
I would like to have a single template defined, and then just tell an endpoint to use that particular template.
Is this possible?
This is not currently supported, but definitely something we can consider in the future as we update the service.
Update: My apologies. Templates are exposed as their own resource. Can you tell me how you are creating your API? I may be able to advise on how to re-use them correctly.
Related
I have an endpoint that I am using to download a file. http://apiendpoint.com/file
We recently got a request to have a second file that we want to be able to get to and I want to add a query string parameter to it. http://apiendpoint.com/file?fileType="A"
I can do in the console but I want to add it to the cloudformation template and haven't been able to figure out how to do so. Any help would be greatly appreciated.
Since you are talking about using a parameter, you won't be able to do this in your cloudformation template, you'll have to implement that in the implementing service (i.e., the service that your API sends the requests to). API gateway in general is only granular to the path level and can only define path level parameters. And by that I mean define, not interpret (unless you're using advanced template mappings maybe, but from your template, it doesn't look like you are).
Oh, and you should have a look at AWS SAM. It could help with cleaning up your template and making it more readable and easier to interpret since it adds some abstraction.
I have an API, and a consumer web app, both written in Node and Express. The API is defined by a OpenAPI Specification. Implemented by swagger-ui-express.
The above web apps are Dockerised and managed in Kubernetes.
The API has a handful of endpoints for managing the lifecycle of a user's registration/application to the service.
Currently, when I need to cleardown completed/abandoned applications, or resubmit failed applications, I employ a periodically run cronjob to carry out a database query for the actions mentioned. The cronjob is defined by a Kubernetes config YAML file. This is quickly becoming unmanageable, and hard to maintain.
I am looking in to having a dedicated endpoint for each of the above tasks. Then a dedicated cronjob could periodically send a request to the API endpoint to carry out the complex task. This moves the business logic back in to the API, and avoids duplication within a cronjob hosted elsewhere. I am ultimately asking if this is a good approach or is there a better workflow documented somewhere I could implement?
My thinking is that I could add these new endpoints to the already-existing consumer API, but have the new (housekeeping/management) endpoints separated from the others.
To separate each (current) endpoint in to their respective resource, I am defining tags within the specification. Tags don't seem to be sufficient for the separation of these new "housekeeping" endpoints.
Looking through the SwaggerUI documentation I can see that I can define multiple definitions (via the urls property) to switch between. These definitions being powered by individual Specification documents. This looks like a very clean way of separating the consumer API from the admin API, is this best practice?
Any input would be appreciated on this as I am struggling to find much documentation on this kind of issue.
I've been building a lot of quick prototypes on Netlify lately. I love the service for its ease of setup and deployment. But I keep running into this conflict between their JAMstacky conventions around API endpoints and my own background in RESTful API design.
To be more specific, say I am building a basic CRUD API in which I can create, fetch one, fetch all, and update some resource type . Let's say a User. If I were designing those endpoints from a RESTful perspective, it would look like this:
POST /users -> Create a user
GET /users -> Fetch all users
GET /users/{id} -> Fetch one user
PUT /users/{id} -> Update a user
Now, if I were setting this up on AWS, perhaps with the serverless framework, each of those endpoints would be their own lambda. But Netlify offers no such configuration options. Which is mostly nice. I hate configuration. But it is difficult to achieve these endpoints at all with Netlify.
Specifically in this case, Netlify automatically creates endpoints which match filenames. So if you have a file named users.js, that creates a /users endpoint. The problem is, that file will be used for every possible permutation of /users. Every HTTP method. Every subroute. They all go to this one lambda. So in order to achieve a RESTful API design, I have to put everything in a single lambda and essentially make it a router. Which seems to defeat the whole idea of serverless.
So usually when you read Netlify examples, which claim to follow JAMstack patterns (something I'm not super familiar with), they do not use RESTful endpoints. Instead they tend to do something like this:
POST /create-user -> Create a user
GET /fetch-users -> Fetch all users
GET /fetch-user?id={id} -> Fetch one user
POST /update-user -> Update a user
So this is in some ways a Netlify question, and in some way a larger question about JAMstack patterns. Is there something inherent about JAMstack that makes it incompatible with REST? Are there different conventions which tend to replace REST for Netflify/JAMstack projects?
"Is there something inherent about JAMstack that makes it incompatible with REST?"
I would say no as it's not related. You aren't building an API with the Jamstack. You are using a service (Netlify) which supports serverless functions that operate alongside the rest of your site. Remember that the Netlify serverless functions are just one option. You could set up your own AWS setup and support the mechanism you want, and still use it in conjunction with the rest of your Jamstack site. I like Netlify's serverless stuff, but it's not going to work for 100% of the use cases out there.
I guess my tl;dr is - Netlify tried to make serverless simple for folks building Jamstack sites, but it won't cover every use case. When it doesn't, you can still use your own solutions along with your site.
I'm building a serverless application.
My ops team has some restrictions that are best resolved by me using a pre-existing (but currently empty) API gateway.
Is there a way to tell serverless to use this gateway instead of creating its own?
Serverless framework does provide the ability to re-use a pre-existing API in their latest update.
You can refer https://serverless.com/framework/docs/providers/aws/events/apigateway/#share-api-gateway-and-api-resources
for details.
Let me know if this helps!
One option is to create the Lambda without any event-configuration in the serverless.yml, and then manually configure the existing API Gateway to trigger the created lambda. I think it is a fairly good solution in your case, since the API Gateway is configured somewhere else anyway.
When writing a RESTful API that needs to access different environments such as a lab/test database and a production database, what's the best practices around setting up the API?
Should there be a #PathParam?:
/employee/{emp_id}/{environment}
/{environment}/employee/{emp_id}/
Should there be a #QueryParam?:
/employee/{emp_id}/?environment="test"
/employee/{emp_id}/?environment="prod"
Should there be a field in the payload?:
{"emp_id":"123","environment":"test"}
{"emp_id":"123","environment":"production"}
In fact I see two ways to handle this. The reason to use one or the other corresponds to what is the most convenient to implement in your RESTful application.
Using a path parameter
With this approach, it should be a path parameter at the very beginning of the resource path. So URL would be like this: /{environment}/employee/{emp_id}. Such approach is convenient if you have several applications deployed under different root paths. For example:
/test: application packaged with the configuration for the test environment
/prod: application packaged with the configuration for the production
In this case, applications for each environment are isolated.
Using a custom header
You could also a custom header to specify on which environment to route. Github uses something like that to select the version of the API to use. See this link: https://developer.github.com/v3/#current-version. It's not exactly the same thing but you could have something like that:
GET /employee/{emp_id}
x-env: test
A reverse proxy could handle this header and route the request to the right environment.
I'm not convinced by the approach within the payload since an field environment isn't actually a part of the representation for element resource employee. Regarding the query parameter approach, it's similar since such parameters apply to the request on the resource.
Hope it helps you,