I'm not able to create a cognitive service to use Video API.
Its currently not available from
Azure Portal.
Does anybody know the process of creating one.
For a variety of reasons, the Azure Portal only lists APIs for which a paid tier exists.
You should be able to find all the information you need on the Microsoft Cognitive Service Video API site, including a link to get a free tier API key.
Related
I have a sheets bound google apps script file that is triggered by the installable trigger onFormSubmit(), which was set up by me. The script, therefore, always runs with my data, no matter who fills out the google form which I am collecting data from.
As a part of this script, the Drive advanced API is utilized, and I create and edit teamdrives using this advanced service.
I want to be able to use the Drive Advanced Service, with all of its authentication management and autocomplete features, while using a service account.
I've seen from other questions on this topic that there are libraries for the management and use of service accounts within Google Apps Script, but they require managing authorization tokens and such of the users which the service account acts on behalf of, and using them to access the API. Going this route, I will have to use the HTTP Interface for the Drive API rather than the Advanced Service, which isn't optimal, but still doable.
Is there a way to authorize advanced services such as the Drive API for a service account acting on behalf of a particular user of my G suite organization in my scenario?
Thanks in advance!
API Keys in web side context are never secured, this can be a big problem if API services are paid for. How to solve this problem in Azure Cognitive Service context ?
I assume you are referring to not exposing the keys to the end user who is browsing to your website, as opposed to securing the keys on the webserver itself from another admin on the server.
This isn't really a Cognitive Services question, but a question generic to any secrets you want to keep when hosting a website (or creating a mobile app, or really any app that uses some sort of key or password).
The short answer is, don't give the key to the client, which means that the client can't directly make the call to Cognitive Services, and you have to have code running on your web server that makes the call.
Generally you would do one of two things:
Code running on your web server would make the call to Cognitive and then process and display relevant results to the user via the webpage.
Your web server would expose an API, and then you would have client side script call your API. Your API internally would call the Cognitive Services API and return the data where the client side script would process and display the results.
You can also find similar info at How to protect an API Key when using JavaScript?, or a web search for something like 'web development protecting api keys javascript'.
In my application , I use the following APIs of the companies API,
https://api.linkedin.com/v1/companies/id={id}
and
https://api.linkedin.com/v1/companies/{id}/updates?event-type=status-update
With the new API program, do I need to change my existing application ? I find the description on the linkedin developer website regarding the same as not comprehensive enough. If I need to continue with the app, do I really need to get into a partnership program with linkedin or can I continue like I do currently.
We recently contacted the LinkedIn Support regarding the changes.
So first endpoint will be available to you without getting into PartnerShip program. The following endpoints are the only ones that will remain available for use:
Profile API — /v1/people/~
Share API — /v1/people/~/shares
Companies API — /v1/companies/{id}
The second Endpoint will require Partner Ship program with LinkedIn you can apply here
But it will not involve code changes because they will give privileged access to your App. At the time of applying for partnership program they will ask for LINKEDIN_APP_KEY and LINKEDIN_APP_SECRET. They will provide access to these KEY and SECRET.
Is it possible expose and sell google cloud endpoint as an Api? I have created a simple but useful cloud endpoint. I want paid customers to access it directly as an api. How will I create a client-Id or API key dynamically for such clients, etc? For example, google also sells search service as API, where any user can go generate its own API key and Secret, and start using google search service.
Right now, no, or at least not without a lot of work.
The current product was designed with the "same party" use case as the primary goal (the API producer and consumer are the same). There are a number of things that would need to be added to the product to enable the kind of use you're describing. First and foremost on that list would be some kind of API consumer dashboard (like the one Google offers developers for consumers of its APIs).
Endpoints is built on the same API infrastructure as the rest of Google's APIs, and Google does offer this feature on some of its APIs. That may give you a sense of where the product is headed in future iterations.
How to generate the API of my Site ... www.volvobusesindia.com so that i can provide my site API to agents so that cthey can vbook tickets using our API ?
i want the bus booking search box appear in the site will be displayed in others website ?
You need to either create WCF SOAP based webservices or WCF REST based services.
You then need to publish these on a web server so it can be accessed by the agents.
You need to document all the API methods and parameters so it is easy for the agents to use your services.
You also need to have an authentication/authorization system in place to ensure your services are used only by the authorized agents.
Actually, you have to have the 'API' first, and then you build your website as a front-end to the API.
An API is just a set of public methods. That's all. For a desktop application, these methods will be in a dll. For a web application these methods will be Web Service, or HTTP Get or HTTP Post methods. API is just a nice name for this.
You then document all the calls available. You use the document to build your website, and you give the documents to others so they can build their website.
The API is the foundation of the system.