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.
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
Alright, A friend and I are developing an App where I'm developing the back-end and he is developing the front-end. The project is separated into two repositories the front-end and the back-end, and we need to implement a payment API.
Now, since we're using the REST API Concept, we communicate both ends through JSON data.
My question is, when we're making the connection to the payment API, who needs to execute that request? The front-end or the back-end?
I know it's a silly question, but first timer here.
The backend will obviously process the payment, I'm not sure which payment API you're going to use. But depending on the API you go with, the implementation will vary. But the actual processing of the payment will be processed in the backend for sure.
It completely depends on the API.
In some cases, a payment can be accomplished via a secure web service call, which would be issued by your friend's REST service. The front end will still need to collect data (e.g. payment amount and card number) and may also need to collect additional information to satisfy the API (e.g. IP address or browser signature, for risk management purposes).
In other cases, the payment is sent directly to the service from the browser. The role of your application would be to render an iFrame housing a page that is reached via SSO. The back end may need to call a service to retrieve an SSO token, or may have to compute an SSO token using a shared key.
You should probably refer to the payment API's documentation. They often have very specific guidance which you must follow carefully in order to achieve payment card (PCI-DSS) compliance. There is nothing special about "payments" that says that allows StackOverflow users to guess anything about its API.
What about Smart endpoints and dumb pipes in terms of different type of requests?
After reading that I was thinking that it's enough to subscribe for some events and deal with that. But now I've realised that sometimes you should have opened API (maybe not for the end customers, but for the API Gateway etc). Is this ok? Or you should "eventize" (transform into event) any request which coming to Microservices cloud?
So, for instance, you have Invoice and Order services.
It's clear that when order created you might use an event which might be consumed by Invoice service to create an invoice. It's clear that for receiving list of last user's orders you may use CQRS on Order service side or even just make new service LastOrders which will keep just projection of required data. But should this request transformed into event or LastOrders should provide API for that and listen for events to update it's own DB?
We do it like this:
All commands are issued as messages in durable queues with type-based routing
Processing takes places in isolated handlers
REST POST and PUT are only created for the API that should be accessible from legacy/external systems
These "command"-style REST endpoints only form command as a message and send it via the message bus
REST GET is perfect for fetching the data and we do not use messaging there, although we could have some message handlers to retrieve data for long-running processes that can only use messages
Command (message) handlers always publish events about what they have done or not done
Downstream event processing can do whatever they want by subscribing to these events
I've some troubles whit spring-social-api for linkedin. After 60 days access token expires and I can't use it to post on timeline of access token user. There is a way to pass this mistake?
Repeating my answer from http://forum.springsource.org/showthread.php?138943-Linkedin-refresh-accesstoken :
Although I can't honestly say I've tried it with LinkedIn, you should be able to obtain the connection (via a ConnectionRepository) and call refresh() on it. In fact, this should work with any OAuth2-secured API (except for Facebook who doesn't quite play by the OAuth2 spec).
I've not tried it with LinkedIn yet, because up until recently Spring Social was working with LinkedIn via their OAuth 1.0a authentication. But it sounds like a good thing to test.
Therefore, Spring Social supports refresh of access tokens. But it is a manual effort on your part to (1) catch the ExpiredAuthorizationException, (2) use ConnectionRepository to fetch the Connection, and (3) call refresh() to update the connection.
What would be more awesome is if Spring Social were to somehow catch that ExpiredAuthorizationException for you, automatically call refresh() and then reattempt the call that triggered the exception; making it seamless for the caller. That is something I've been pondering, but there's no implementation yet.
One possible solution is an aspect. But it'd need to be configured by the developer to properly wrap whatever API binding types (LinkedInTemplate, for example) the application is using. Another option I'm thinking over is to dig down into AbstractOAuth2ApiBinding and configure the RestTemplate that it exposes to handle that exception. It's a bit iffy on whether it can work, but if it does work, then any API binding that extends AbstractOAuth2ApiBinding would automatically get refresh capability...except, again, for Facebook who doesn't play by OAuth2 rules.
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.