I'm need send with Kong (Community Edition) one webhook ( request ) for two apis.
The problem is i use one webhook of third parties, and can only specific one URL ( this not negotiation ).
I use in my app Docker, Traefik, Kong and many apis call throug Traefik and Kong, as show in the picture.
I can't send request the Service1 to Service2.
Create other service is one option but i like avoid this option.
I would like to solution with Kong but any other option is good for me.
Solve this problem using goreplay and work very well.
Related
So, I set up a couple Lambdas and the API gateway. I got it all working! Cool, so then the next step was to require an API key. Ok cool plenty of resources out there on how to set it up.
So I got that working as well and I could POST using postman and python (requests). I can provide the 'x-api-key' in the headers of the POST and it works, no issues.
HOWEVER, and here's the problem: The program I'm going to ultimately be using to POST to my gateway API doesn't allow you to edit the details of your POST. The program is called splunk, here's what it looks like. Basically it posts some payload for you, the headers/auth/body can't be edited by you, it just sends some pre-configured thing. You just provide the endpoint and it does the rest. This works if I do not require an API key.
So I started thinking, ok no huge problem, I have seen APIs before where you provide the API-Key in the URL and it authenticates you fine. So this would be something like:
https://exampleAPI/sendmydata?x-api-key=12345
However, I cannot get this to work in AWS for the life of me. I haven't found anything by googling. Is this something that's even possible?
Thank you!
If you must use API key usage plans, you could consider getting the posted API key parameter to API Gateway endpoint A from LambdaA and proxy it with the relevant headers to API Gateway endpoint B.
I want to send SMS from AngularJS web application using Ozeki sms gateway. Can anyone tell me how to do this? pr suggest me some reference link or code sample.
Plain sending
Assume we skipping other protocols available inside Ozeki Sms NG product (like SMPP, Email, DB etc), and getting to HTTP protocol only, you can go this way:
Prerequisites:
Figure out best way for you to make HTTP request to send SMS
(I'm not AngJS guy so may be there are already few ways to make HTTP-request from Angular, but at least any Ajax method passing params to executing PHP-script for making HTTP request (with curl, file_get_contents) will be totally Ok).
Make sure your Ozeki SMS server is reacheable via IP/domainname etc by your PHP-script so your code can reach its endpoint.
Doing it:
Inside Ozeki install service provider like HTTP Client
http://www.ozekisms.com/index.php?owpn=195&info=service-provider-connections/http-client-connection
or HTTP Server (more powerful version of HTTP Client allowing call back URLs)
http://www.ozekisms.com/index.php?owpn=197&info=service-provider-connections/http-server-connection
Then according (to docs) execute request like
http://server_ip:9501/api?action=sendmessage&username=________&password=________&originatior=__________________&recipient=__________________&messagetype=SMS:TEXT&messagedata=______________
*Some fields are not necessary, it may vary depending on Ozeki version you use.
** port 9501 - is a default Ozeki HTTP port which may be changed in general settings, also it has HTTPS port as well. Basically the correct port is the same which you already use when accessing Ozeki Web GUI.
After executing sending request (try from browser or from something like Postman first) you should get responce in XML format informing you about result of your transaction.
Possible next step... DLRs
Getting delivery reports (if supported by your operator) is a common "i want it too" question.
In case you need them - there is great embedded feature inside "HTTP Server" connector (mentioned above).
Here you can see more details
http://www.ozekisms.com/index.php?owpn=431
"reporturl" - is a field you may use to set kind of "call back url". In other words in this optional field you may specify full URL and list fields to be passed along. So you only have to create your own endpoint to catch them (as GET request from Ozeki server) and use inside your software.
Currently all the Fulfilment requests originating from api.ai are, POST requests to the base url configured in api.ai Fulfilment section. But to be able to have proper routing (microservice style) set-up on the server side it would be more worthwhile to append the action in the POST URL.
For a substantially large project, there can be hundreds of fulfilment actions and managing all of them in single monolithic project is cumbersome. If the action comes in the URL, then we can configure and organise the actions into multiple cloudfunctions in case of firebase hosting / server side microservices.
Edit:
As answered by matthewayne, I can use my own proxy set-up to route the requests to achieve the goal. But I don't want to introduce any additional delay into the request processing. Because I am expecting huge number of webhooks being fired. This would be a very easy implementation for Google api.ai team to incorporate that allows for a greater flexibility! Hence expecting an answer from google team!
Currently this isn't possible with API.AI's webhook design. I'd recommend setting up a proxy service that unpacks the webhook requests from API.AI, inspects the action and sends the proper request to the proper microservice endpoint and then forwards the response back to API.AI once the microservice has returned its result:
I am learning and working on building some wso2 sample prototypes.
I have created a proxy service and tried using it with the tryit tool inside.
But i don't know how to use it externally. i mean how to send data to the proxy service because in API there is a endpoint created where the request is sent.
Is there anything like link to request or how to use it externally in some application.
You can use SOAP UI. Please check the article.
The easiest way to call Your proxy service is to use some Rest Client on Your Browser. I use Add-On in Firefox (RestClient i think). U can create there whole request (json, xml), add headers, Authentications or Content Type. It should helps U to call any services in wso2.
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests