I am trying to implement an API that has asynchronous endpoints, for example, create/delete only initiates the operation (see screenshot), but then there is a different endpoint that checks the actual request status.
Can this be implemented as one module in Integromat? Or should there be a separate module for checking the status?
If I understand your question correctly - you will need 2x HTTP (blue) circles for this.
In my example- I would authenticate first using some API and get authentication parameter from that first API call.. then I would pass it to the next HTTP Blue circle API call.
Although more information is needed in your question, I feel the answer would be 2 subsequent HTTP API calls within Integromat
Related
Is there a way to see the response to a request in the logs generated through appinsights?
I’ve got several apis, and I can see the client making the calls when querying the requests table, I can see the status of the request but I can’t see what was sent back to the client.
Also when I click appinsights in my APIs it says
‘Set up app insights without changing code’
But above it, there’s a green tick saying ‘connected by Instrumentation code’
Does this mean it’s connected and working?
Does this mean it’s connected and working?
Yes, Application Insight connected to API.
Is there a way to see the response to a request in the logs generated through App insights?
If you want to see the response of your request/Custom Events or Custom Metrics, you need to use the Custom Telemetry in your API to get the response in Application insights.
Note: Make sure you can use it for testing purpose. In an application insight who ever have the access of your subscription of the specific resource they can view the telemetry data.
Reference
Custom Metrics in API
I am building a microservice application, and I try to follow the best practices. I use event sourcing and event driven state transfer in many places, but I realized that sometimes I just need to call another service in an asynchronous way to kindly ask it to do something e.g. send out a registration email (as the email service is a technical component and not a domain). I noticed that many times, services just call the other's service API endpoint, but that wouldn't be asynchronous. As I don't expect any returned value when calling from another service, the command would only produce events, RPC is not necessary.
In the end, my plan is to implement commands/actions that can be triggered by clients from REST API (then the commands may also produce responses) or by events or other services from RabbitMQ or similar. This leads me to how should I define the data structure of the command/action, is there any specification for that? Or existing solutions for Python? Or should I do something differently?
I am using DocuSign REST API 3.0 to integrate with my app.
After a DocuSign envelope is voided, if I invoke EnvelopesApi.ListStatusChangesAsync for the envelope, I get back an EnvelopesInformation object, which shows both a VoidedDateTime and a VoidedReason property. This is exactly what I need to update my database but all the documentation tells me I should implement
a webhook to receive status updates instead of invoking the API, so I implemented the webhook.
However, when DocuSign invokes my webhook after I void an envelope, I get an DocuSignEnvelopeInformation object from DocuSign, which does not appear to have a VoidedDateTime or Voided property. There is a VoidedReason property, and there are properties for other status dates, such as Created and Sent. Why no Voided property?
What this means is that after the webhook is invoked (and updates my database with incomplete information), I still have to invoke the API to get the VoidedDateTime into my database. Did I just waste my time implementing the webhook? Or am I missing something?
You should explicitly select Envelope Voided Reason checkbox in your Custom Connect configuration. Once this property is selected then you will be able to know the reason why this envelope was Voided.
Webhook is a notification system, where it will notify your System with some data/metadata about the envelope, and if that data does not seem sufficient for your requirement then you need to use API to pull the rest of the data. If Webhook is not available then you need to do a Polling mechanism using some scheduler to keep polling DocuSign after certain interval which does not seem to be a good design and not very scalable. So Webhook design helps your system to know when to call DocuSign platform.
Please note, it seems you are using SOAP API, but I would recommend to implement a new API integration with DocuSign's Rest API as it will have latest features which might be missing from SOAP API.
I have reviewed every topic that seems relevant and I believe I am having a problem because the configuration in which I am attempting to use this service is different from any of the other postings.
I can get acceptable Reverse GeoCode results only without a Key.
But acceptable is not optimal. The Guide documents filtering which would be applied on the server side to reduce the number of results I would receive to check to determine which result is 'best'.
I do not believe that the ability to get server-side filtering is a Premier Service; I do not have a Premier License.
No matter whether I use a current Browser Key or Server Key, every request will result in REQUEST_DENIED status.
At console.cloud.google.com/apis I have enabled "Google maps JavaScript" and just by reading all the other postings, I have added, probably unnecessarily, and with not change in the result: "Google Place API Web Service".
My only remaining guess is that my request is being denied in relationship to the terminology of the service agreement requiring that this service include the display of a Google Map. My application DOES display a Google Map, but I do not see how to let the Google Maps Server know that. May API stack is using the Javascript API with XML results requested via this URL: "http://maps.googleapis.com/maps/api/js?language=en&libraries=places", and the GeoCoding requests [forward and reverse] work fine via this URL:
http://maps.googleapis.com/maps/api/geocode/xml? but adding a key="" in order to take advantage of server-side filtering is always denied.
What am I missing that needs to be passed in the request in order to have my api key honored and for me to get a better result set consuming less network bandwidth?
As you use Geocoding API you have to enable it in your project. You have to generate a Server API key and use it with your request.
The official documentation covers this subject:
https://developers.google.com/maps/documentation/geocoding/get-api-key
For Maps JavaScript API you have to use a Browser API key:
https://developers.google.com/maps/documentation/javascript/get-api-key
Is it possible to either turn off the api explorer completely or limit the access to it?
I noticed some logs in my app that come from failed requests executed from a browser. My api is only consumed by an Android app so the only place where they can come from is the api explorer. Also the api access is limited to 1 web and 1 android client id.
Unfortunately no. The API explorer works by using the Discovery Service associated with your API, which is not actually part of your backend, so you can't specify auth or visibility for those URIs.
The list method from the Discovery service is used to generate the list on the APIs Explorer app using your app as base:
discovery.apis.list:
your-app-id.appspot.com/_ah/api/discovery/v1/apis
When someone clicks one of the APIs from the list, the full discovery document is retrieved for that apiName and apiVersion using the getRest method from the Discovery service:
discovery.apis.getRest:
your-app-id.appspot.com/_ah/api/discovery/v1/apis/{apiName}/{apiVersion}/rest
If you are looking for ways to prevent the executing of the API, check out Cloud Endpoints: Control who can execute API through API Explorer
endpoints makes auth easy and you can get the current user. You should use auth to ensure people don't mess with your private apis - otherwise people could trace what kind of post or get requests you're sending anyway - auth is always a good idea rather than trying to keep your apis secret.
If you're building a secret product and you don't want your competitor to find out, you could perhaps use some obfuscation method on the backend and on your client which makes the apis unreadable.
Also a user messing with your apis shouldn't break your database - or if it does - it should only break it for the user that was being foolish. Having logic in your client for how apis are used so that the backend doesn't break is a bad idea - the backend apis should take care of themselves and not worry about how or why they are used and who by for what purpose.