We have multiple API's running for an enterprise. As per our limitation client will allow only one static IP to receive all Inbound/Outbound requests.
So, we need to expose a single API as a bridge between the client system and API's running behind.
How to approach this design?
How to design the URL for this proxy API?
What edge functions does this API need to provide?
Any help would be highly appreciated. Thanks!
You do not need to use web services consumer, yet will need to create a POC.
Define A RAML with required path and RAML, scaffolding should give you API took kit, and connect an HTTP request
use HTTP request
Examples:
Define Headers --- attributes.headers.id etc
queryParams ---- attributes.queryParams.date
if you are sending JSON payload across from ex: postman, change Mime type to application/json
sample http properties for request
http.host=myHost
http.port=8872
http.base.path=/myproxy/services
Related
I have some REST APIs my backend server listens for (I used node express).
I want to use my friendly url api.mywebsite.com to forward all routes to horribleuglybackendname.aws.com, e.g.
api.mywebsite.com/some/route -> horribleuglybackendname.aws.com/some/route
I want to use API gateway to simply forward any routes to my backend. If I create a HTTP API (not REST) this seems easy to do but if I create a REST API I cannot see how to configure it. Perhaps you can't? If you can't why not? What is the alternative?
Thanks
So it seems $default is for HTTP APIs only. The UI is different between HTTP and REST API configuration. If you want to do a catch-all route for REST APIs you need to use {proxy+}.
This is good (ctrl-f for catch-all and you should be set)
https://aws.amazon.com/blogs/aws/api-gateway-update-new-features-simplify-api-development/
What is the most common approach to URI naming for API which uses both HTTP and WebSocket protocols for similar requests? Are there any common conventions for that?
Lets suppose we have a HTTP request returning the collection of users:
localhost/users
This request should return a list of registered users.
On similar WS request, the server should open WebSocket channel and send a list of users to the client over it every time the list is updated (e.g. user was added or removed, etc).
How should the URI for WebSocket request look like?
I see several options:
It may be the same, localhost/users. The difference should be only in the request headers (Upgrade: WebSocket). The drawback is that it can be confusing as requests with same URI return different responses dependent on provided headers
localhost/users-ws. This seems a little bit ugly for me as the API grows each time we have similar WS request for a HTTP request
localhost/users/ws. This breaks the possibility of extending the URI with variable, for example we can't use localhost/users/{id} here no more.
Store all WS requests under common ws domain - localhost/ws/users. This is also ugly as we break the order of domains in the URI and can't redirect requests with users domain to the specific handler
So at the monent I don't see an option without obvious drawbacks:)
If someone can provide any examples of big projects like StackOverflow or GitHub where WS and HTTP are used together, it will be very helpful.
I am not aware of any common naming conventions for WebSockets but for web APIs there is a naming convention to start the route with /api/, example api.example.com/api/users.
Following that practice, it could be argued that example.com/ws/users could be a fitting route name to use.
I have a BizTalk application where I have exposed schema as a RESTful web service, which calls another REST service. I am able to successfully handle GET, DELETE request.
Is there a way to handle POST request without writing a pipeline component to serialize the POST request to a schema?
Also, the application may have to handle several POST calls, so will it be possible to serve this from one single receive location and then filtering the request on the send port?
Please let me know if any more details are required.
So, here's the thing. You're mixing together some things that technically have nothing to do with each other.
For instance, a Plain Old Xml (POX) service, usually a POST, does not 'expose' a Schema in the way a SOAP service does. It just takes whatever content is POSTed to it.
Following that, serialization/deserialization is also a concept more related to SOAP that POX or REST.
So...
Yes, but what exactly are you doing?
Yes. A plain http endpoint can accept any content type. Once it's over the wire, all the normal BizTalk processing rules apply.
I am having confusion around http text 'post' in terms of webservice context. We are having a web service which is built on SOAP protocol, now the integration partner wants to eliminate the SOAP portion of the XML message and wants us to post XML message as 'http text post'.
Is this REST HTTP POST? Please clarify.
POST is an HTTP request method, of which there are many (ex. GET, PUT, DELETE, HEAD...). POST is used to submit data to a server for processing, whereas GET (for example) is used to retrieve data for reading. You can read more here. These methods are used for all HTTP communication, whether the target is a SOAP/REST web service or an Apache server hosting a regular website.
SOAP normally operates using POST requests, although it is possible to use GET with SOAP 1.2 as well. GET requests have more restrictive size limitations than POST requests.
I am writing a REST API providing CRUD operations on resources.
I'd like the users to be able to register to some resources changes and get the updates via server push. For the server push I will provide support for reverse ajax, hidden iframe and websockets. In order to be as REST as possible I created a Streaming resource which handles the registrations and the connection to the client:
Streaming resource:
URI uri : A GET against this URI refreshes the client representation of the resources accessible to this user.
bool WebSocket : Indicate if websocket is available on this server
bool ReverseXHR : Indicate if ReverseXHR is available on this server
bool HiddenIframe : Indicate if HiddenIframe is available on this server
Registration[] Registrations : The set of registration tasks.
OpenChannel : Open streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
CloseChannel : Close streaming channel from webserver to client. GET parameter type=(websocket|xhr|hiddeniframe)
A call of openchannel?type=websocket would open the websocket and start streaming the data of the registered values.
I've read many articles but I am still a bit confused. Can I still call my API REST after doing this? And if no (or yes) why?
Thank you for your help!
Firstly, always implement what makes sense to solve the problem you face. Conforming to a given architectural style provides specific benefits but this should not exclude pragmatic solutions to a given problem.
But having said that, it seems like you're using streaming of resource data as a way to "tunnel" information back & forth between the client and the server. I'm pretty new to this but it seems to me that the tunneling data goes against the uniform interface constraint in the REST architectural style. Tunneling over HTTP is one of criticism level against soap based services.