I see on the documentation for REST API how they explain the Model architecture, but not for HTTP API. Is this because the HTTP API doesn't require models?
For example I have this data in DynamoDB:
Usually in the REST API one would perform user input validation which is part of the model (if I'm correct), I don't see that option in HTTP API. Can someone explain me how I build (or if it's needed) this model for HTTP API? For example, what if the user goes to /todos/{id} ?
Is this model concept moved to lambda or somewhere else or still lives in the gateway?
Thanks
HTTP API is more recent addition to Api Gateway, it is much simpler, cheeper and easier to use but will not support bunch of features that REST API supports. Model Validations in one of those un supported features. Here is the comparison.
All validations will reside within the application code.
API Gateway data transformations are not supported with HTTP APIs, but are supported with REST APIs.
You can think of API Gateway's HTTP API as a streamlined version of the REST API. HTTP APIs have fewer features than REST API. As a result, HTTP APIs are faster and cheaper. The trade-off is that you have fewer features to choose from when working with HTTP APIs.
If you want to use data transformations, you'll need to use REST API. If you'd prefer to use the cheaper/faster HTTP API, you'll need to do data transformations yourself (e.g. code you write yourself in Lambda).
Related
Most of our bespoke applications in AWS are containerized .NET Core apps and so far we haven't needed to build any SOAP APIs - virtually all of the APIs that we've delivered (whether exposed publicly via AWS API Gateway or internal only) are JSON RPC following a RESTful architecture/design principles.
We also have a third party COTS product deployed into our AWS account that produces SOAP webhooks and we need to receive and process these SOAP webhooks produced by the third party COTS product.
Ideally we don't want to build a bespoke SOAP API / translation layer - even if WCF is now supported in .NET Core / 5+, I'd much rather we just stick with HTTP/REST and .NET Core WebAPIs which is well understood by our delivery teams. Ideally there is a way e.g. a native AWS service, that would allow us to translate the SOAP request to a HTTP/REST request. Does anyone know if there's a native AWS service with these capabilities?
Cheers.
The translation would be something like the following
HTTP method GET/POST + SOAP operation verb endpoint
POST /soap/cancelOrder <message>{id}</message>
<=>
HTTP method GET/POST/PUT/PATCH/DELETE + REST resource noun endpoint
DELETE /rest/orders/{id}
Without a naming convention it is hard to translate. Another issue here, that real REST services return hypermedia with a flexible structure, while SOAP services return SOAP message with a ridig structure defined in WSDL. Yet another issue that SOAP is stateful, while REST is stateless.
Maybe in edge cases it is possible to automatically translate for example by services which do only basic CRUD without any real business logic.
We are altering our webservices to require an application using them to provide information on the real user who is requesting the data. For REST services we are implementing this using an X-On-Behalf-Of HTTP header. Should we do the same for SOAP services? Or better put it in a custom SOAP request header? What are best practices in this area?
Though answer depends on internals of your application architecture and other design principals you might have followed.
Its ideal to keep Rest/SOAP services implemented the almost same security Model, hence if you're planing to use `X-On-Behalf-Of' HTTP, it make sense to use same in case of SOAP services as well.
But, in case of SOAP it you're using WS-Security or some Kind of Custom SOAP Header to do Authentication/Authorization in every SOAP Call, it makes more sense to Modify SOAP header itself to get the additional On-Behalf-Of' detail as well rather then Custom HTTP Header forX-on-behalf-of`
Refer Message 2 - WS-Trust Token Exchange Request section for more details.
I am certain I need to use an API Gateway, but I can't understand the main differences between the different tools in my use case scenario.
Currently, I have multiple services (DBs, Mobile App, Web App and some additional systems. Consider there are 15 different services) that communicate with each other through REST APIs. This is difficult to manage and test, so I would like to change the architecture into something more like what Netflix is doing with Zuul.
Ideally, the services don't know about the other services. They send a request to a specific endpoint (the API Gateway). Then, the API Gateway interacts with the necessary services and sends the response back.
Here is one example in practice: a service sends a request to a custom (endpoint) connector, the request is parsed, broken down into smaller requests that are sent to other services (that own the specific content requested), get the content back in the response, gather all the responses, create a final response with all the content gathered, send the response back to the first service that sent a request.
I need high availability, scalibility, fault tolerance, the ability to monitor and test all services in one place, ability to do canary testing, easy to add new services and manage the older services. I value open source software and mature software. Should run off premise.
The best solutions that I believe would solve my problem are: WSO2, Apigee, Zuul and Amazon API Gateway. I don't know which is more appropriate for my use case. I have looked at others, but I haven't found any advantages in features or cost against these 4.
Thank you for your feedback regarding advantages and disadvantages regarding these technologies! Other suggestions are also welcome!
Notes:
Not all of my services are on AWS, but some are.
The system needs to handle peaks with tens of thousands of requests per minute that happen regurarly, but never continuasly.
You can also consider the Forum Sentry API Security Gateway from Forum Systems (I work for Forum Systems).
Based on your example use case, if each of the "smaller request" services are using the same protocols (e.g. HTTPS), message formats (e.g. JSON) and security characteristics (TLS, authentication, etc.) then the solution should be relatively straight forward.
If each service is using different identity or message formats, say, then your API Gateway solution will also need to have strong capabilities around identity and message conversion. For example, one small request may require a BasicAuth header to authenticate to the service, whereas another small request may require a SAML assertion.
As you have landscape of different microservices, wherein each microservice has its own business context and is accessible by REST endponit. In this case, your client need not to aware about each microservice and thus API gateway comes into picture, using which you can have one entry point to all microservices landscape.
There are different API gateway solutions available like you said apigee, apiman etc. These framework gives some basic implementation of features required in API gateways like request throttling, monitization of request calls, authentication handle, centralized security etc.
Netflix's Zuul provides the filters which you need to implement yourself. So, if you are using Zuul, you have to implement all the features which you want to put in your API gateway by yourself.
I hope this explanation helps!!!
Can I add multiple endpoints to 1 API in WSO2 Api Manager?
As far as I know I have to create a context and a version. The background is that I just want to make a request like https://api.manager.com/rest/1.0/userList or https://api.manager.com/rest/1.0/tasks.
The userList REST-Controller is implemented on backend A and tasks REST-Controller is implemented in backend B. (A and B are separate web applications)
As far as I know I have to create in my API Manager two APIs with different context values.
The API Manager application would simply subscribe both APIs.
But this would mean that I have to change my requests on the javascript side. This is in my opinion not good because I dont want my javascript application to care about the context. I want that the API Manager delegates to the correct backend automatically. Is this possible? What is best practise?
You can have multiple endpoints per API using Dynamic Endpoint Feature. When creating the API you need to set the Endpoint Type as "Dynamic Endpoint" and upload a mediation in-sequence that sets the "To" header. Within the sequence you can specify your logic to route to the correct endpoint (setting the correct "To" header) according to the request path. Please read [1] for more information.
[1] http://blog.lakmali.com/2016/08/dynamic-endpoints-in-wso2-api-manager.html
We currently have a SOAP based web service that our in house applications use to authenticate users. Basically, they send a SOAP request with the username and password. The web service authenticates their credentials against our data store and returns user information if the authentication is successful. The web service is secured using BASIC authentication and SSL.
We need to make modifications to this web service and I was considering re-writing it as a REST service. The REST services I have created in the past have been fairly simple and had no need for security. I have never created a REST service that used sensitive information, so I have a couple of questions / concerns:
First, is there a best practice for sending sensitive query parameters (user credentials) to a REST service securely? I can still use the BASIC authentication and SSL.
Second, if I send a query to a REST service using POST, is it still considered RESTful, or is GET required for REST queries?
You can use SSL and Basic authentication with REST web services as well.
HTTP GET is usually used for data retrieval (queries) but you can use HTTP POST as well. GET is especially useful if you can use any type of HTTP caching. POST is usefull if you need to transfer a lot of data to define your query or if your web service operation expects some complex data format instead of simple arguments.
Instead of doing the authentication via REST, you might also consider a networked authentication protocol to use in conjunction with web services. Technologies like Kerberos and OAuth were designed for these sorts of use cases.
To answer your questions, however:
REST encourages you to leverage HTTP and related protocols, so using SSL and BASIC authentication is quite appropriate.
REST encourages the use of not just GET and POST, but even other HTTP "verbs" such as PUT and DELETE. Use GET only for idempotent operations with no side-effects.
Going from SOAP to REST is taking a step backward as far as security goes.
As far as best practices:
Don't roll your own security. Use a framework or existing library that has been peer-reviewed and tested.
Don't pass unencrypted static keys. If you're using HTTP Basic and sending it across the wire, encrypt it.
Ideally, use hash-based message authentication code (HMAC) because it's the most secure.
Why REST security doesn't exist