What is the impetus for the author of https://github.com/firebase/functions-samples/blob/master/fcm-notifications/functions/index.js Line 74 to use a Legacy API?
Put another way, is it possible to use Firebase FCM non-legacy API to achieve the same outcome?
I checked with the author of that sample. Back when the sample was created, what is now called the legacy API, was the best API available.
When the new v1 API was released we looked into upgrading the sample to use that. But (as Umar commented) since the new API no longer support sending to multiple tokens with one call, that upgrade got deprioritized after some other tasks.
I recommend that you file a bug on the Github repo, to get the sample updated to use the latest API. I'd also recommend filing a feature request to get "sending to multiple tokens in one call" back into the new FCM API, since it seems like a rather useful feature.
Update
It seems that so-called multi-cast send operations are coming to the V1 API. From an #AskFirebase video about FCM:
We are planning to add a multicast feature to HTTP V1 that will allow you to send to multiple tokens in a single API request.
Related
We're currently working on our API based on Google Cloud Functions together with Google's API Gateway.
As every customer who buys access to our API should get their own API key, I'm wondering if there's a ways to create those API keys using and API. What I want to achieve is that a customer is able to request an API key in their own settings, so klick a button, this triggers a function, generates a key and shows it to the customer in front end.
After searching for quite some time, I didn't find anything about how this could be built. It could also be that my approach to this is totally wrong - if that's the case, please roast me and give me some advice with it!
Thanks in advance for your answers!
Google credentials can not be created programmttlcy they must be created manually.
In fact, there is something. A while in beta (more than 1 years ago) and quickly back in alpha, and undocumented (or pretty bad)
As you can see in the gcloud alpha command, you can use API Keys with CLI and API. Use this command to test and discover more how you can use API keys.
gcloud alpha services api-keys create --display-name="created by API" --log-http
USE WITH CAUTION
Firstly, I have no update on this API, will it survive or not? The lifecycle and the "no news" from Google is strange and keep in mind that the API can be removed at any time.
Secondly, API Keys is a long lived token and it's not recommended for security reason. But sometime, it's better than nothing, so to use it when no others solution are possible, it's acceptable. Else, prefer OAuth .
Eventually, API Keys authenticate a project, not a customer/user. You won't have it in header data after the API Gateway request forward. Only the Project ID (or Number, I don't remember). Thus, if you want to differentiate each customer/user, you need to create different projects, and generate a keys in each project. Same thing if you implement rate limit on API Gateway: Quotas are per project and not per API Keys.
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'm adding a support of CyberSource to our system and just got new requirement about 3D Secure support.
I've already implemented some flows using CyberSource REST API:
Payments
Card tokenisation via Flexible token
I'm a little bit confused, because I can't find any information about implementation of Payer Authentication in conjunction with the REST integration. All I found is the documentation for Simple Order API and SCMP API.
Am I missing something? Am I supposed to use any of the aforementioned docs or there is some separate document for REST API? Or I should use different integration method instead of REST?
Update 6-14-18: The payer authentication (3-D Secure) is now available with the REST API.
The payer authentication services are not available through the REST API at this time. I know they will be, but don't know when.
The only other option is using the SOAP API (SOAP Toolkit) or pre-built client (Simple Order API). SCMP is a legacy API and should not be used.
Is it possible to get data from Healthkit the same way as you would query regular API (With user's consent) to store in my webapp?
Something like: healthkit.com/api/v1/user/GetWeight
If yes, where can I find a list of available methods?
If not, are there any workarounds?
You'll have to build:
your own REST API service to store and retrieve the desired data;
an iOS app that accesses the data on-device using the HealthKit SDK and POSTs it to your API.
Neither step is trivial. Good luck!
An alternative may be to install Google Fit on the iPhone, which would connect to healthkit and sync that data to the cloud, which can then be queried via Fit's REST API https://developers.google.com/fit/rest/
If it's a REST/json API you want it's not available and i guess it never will be.
HealthKit is just a standard API available in the IOS8 SDK accessible from application running on a iDevice and written in objective-c/swift.
Not sure if this question is still relevant for someone, but now you have the option to use shortcuts to gather the desired health data and post it to your own api, also you may use automation in order to make it all happen without any hustle.
I am creating a client program that calls various APIs, one of which is the Evernote API, through purely HTTP calls, without the use of any SDKs provided by Evernote. I realize that this makes my life harder, but it makes the lives of the users of my product much easier.
So far I have been able to authenticate with oauth 1.0 to the Evernote server. However, it's not immediately clear how to make the HTTP call after I have the oauth_token.
Where is the endpoint to make API calls to create a note on an oauth-authenticated Evernote user account? What are the url parameters for such a call? Or, what are the requirements to include in such an HTTP request?
Does Evernote use HTTP to make such calls anyway? If not, what do they use?
Do I have to format the note in XML format, or does it accept JSON as well?
Evernote does not have a RESTful API. According to the CTO, it's due to a requirement to shuttle very large amounts of data and HTTP is not efficient. There is a project on github aiming to implement a RESTful API for Evernote.
https://github.com/ttddyy/evernote-rest-webapp
CTO's Reasoning:
http://blog.programmableweb.com/2013/10/03/is-evernotes-restless-api-approach-a-model-for-other-api-designs/
I haven't used Evernote in years and never used the API.
Evernote uses thrift which can be a bit tricky to deal with. This choice is explained in this blog post. I really advise you to use the SDK as it hides all the thrift complexity.
As mentioned above, a rest wrapper is available on github. It seems very cool but it's new and not official. Use it at your own risk.