I'm trying to use a Google API for a project, but I have a problem ;
Sometimes, there are versions like v1beta, v4.3, v2alpha2.5 etc, guessable but I don't want to bruteforce it to find the versions.
So I was wondering, how to list all available versions of an API without using the endpoint https://discovery.googleapis.com/discovery/v1/apis ?
Like a parameter for all individual APIs, would be cool to have a <api>.googleapis.com/$discovery/rest/versions
Thank you in advance.
I have been working with Google and Google Cloud APIs for more than a decade. There is no shortcut that I know of. Google does not publicize all API versions.
Knowing all available API versions will not do you any good in most cases. Some API versions require prior approval (whitelisting) to use them. Others might be in alpha status and should not be used except in certain situations. Some API versions require a relationship with the PM to obtain details. Some API versions require an NDA for either the API, the service, or both.
For the APIs that you require, subscribe to or follow the blogs and release notes.
Unless you have a specific requirement, only use the latest production (GA) version. GA versions have published documentation detailing the interface, methods, and parameters.
Related
I need to call the Microsoft Graph from a Google Appengine Python application, this requires oAuth2 authentication.
Google provide the Google API Client Libraries for calling their own REST api's (such as Calendar / Drive / Youtube etc) - is it possible to use the library to call other non Google REST API's such as Microsoft Graph?
If not has anyone used another library to do so from Appengine Python. You can not use the Microsoft supplied python SDK as this requires python version 3+ and Appengine only supports 2.7.
Thanks in advance,
Ian
The authorization token you receive from Google will only work with their APIs. You'll need a separate token for use with Graph. For this you can use ADAL library.
Since you need to stick with 2.7, you'll need issue REST directly. The existing SDK (as you noted) requires py3. You may want to take a look at restclient for this. Its been a while since I've had to use this lib but I recall it really simplified calling REST endpoints.
I'm looking for API documentation on how to interact with user accounts. For example, checking if a user exists, creating a user, updating a user, getting user properties. I've been to doc.sitecore.net but I still can't seem to find any of this documented. Is it documented and where can I find it? If it is not documented, what other resources can I access?
In 6.x versions, I see that some of the functionality I need is in Sitecore.Security.Accounts. However, I don't know if this is still current or if there is a better method for 8.1 and future versions.
The 6.x guidelines are still the most current, and as of 8.2, there has not been any major changes to that API, so the Security API Cookbook is still your best bet.
https://sdn.sitecore.net/Reference/Sitecore%206/Security%20API%20Cookbook.aspx
To my knowledge, this part hasn't been changed since Sitecore 6.x, so you should be safe to use this resource.
So I've done some digging, but came up with nothing thus far because I feel that this would be a close to impossible task. But I am more than willing to look on my own, I wanted to know if it was possible to access Google related resources using QT Creator. So For example if I wanted to use say Google analytics, what would I need to research? Would I need to have some sort of app-engine side?
Thanks!
You can access most of the Google products by using the corresponding API (AppEngine is not required for that). This link lists all available Google APIs. You can then access it using the Google API Client for C++, but the C++ binding seems to be in alpha.
Edit:
It seems that Google stopped the development and support of the C++ binding for their APIs. The library source code can still be found on Github.
I am looking for any information on the Microsoft TFS Web Services. First I know accessing the Microsoft TFS Web Services directly is not supported and Microsoft provides no documentation for doing this. Therefore I am not expecting any Microsoft support or assistance here.
I know all about the .Net API available for TFS which only works on Microsoft Operating Systems. I have used these many times on Windows, however I need to do non-Windows work to access TFS, I cannot use .Net and I cannot use a Proxy (or "shim") to be installed on a Windows computer to provide Web Services for the .Net API.
I know Teamprise reversed engineered the web services and they successfully used this knowledge to make a very good cross platform Team Explorer and command line implementation in Java to access TFS. So good in fact they were purchased by Microsoft and the product rebranded and rereleased as Microsoft Visual Studio Team Explorer Everywhere.
I have also tested the .Net API against Mono on several non-windows platforms and they are not compatible. The initial NTLMv2 authentication is using calls not supported by Mono. They appear to be, understandably, making Win32 specific calls for NTLMv2 support.
Therefore before I go to the trouble of reverse engineering them for myself, and dealing with NTLMv2 to do it. I am hoping that there is some hidden or buried information on the web that someone may have documented some portion of the web services for TFS from 2005, 2008 and/or 2010.
Please no comments or posts about how this is not recommended or supported by Microsoft, that I should find a way to use the .Net API, or suggesting the Proxy/Shim is the best solution. I am fully aware of the Microsoft's official stance on this, and what the supported workarounds would be.
I'm not aware of any documentation for the TFS web services, but I can share some tips on calling them.
The NTLM authentication you mention is really a separate layer: you must authenticate to IIS before it lets you call TFS web services. I'm not aware of any Open Source software that will do NTLM auth for you, but TFS 2010 makes it easy to enable "Negotiate" authentication (SPNEGO on Wikipedia, Authentication by using Kerberos Ticket on MSDN). Negotiate supports both NTLM and Kerberos subsystems, and there may be some existing software you can use to drive it using the system's Kerberos libraries (I think curl does it). If you had to build it yourself, it would probably be easier to go the Negotiate-with-Kerberos route.
Once you're authenticated, you can start calling services. Start by pulling down the WSDL for each service (stick a "?wsdl" suffix on each endpoint URI). Hop over to where TFS is installed and explore the web application directory for endpoints. There are several versions of some endpoints for back compat with TFS 2005 and 2008, but usually new versions are not redundant (they add new stuff). You might have a favorite SOAP client library already (there are many for Java), but I can't really recommend any because we wrote our own at Teamprise.
Services like version control, build, and common structure are easy to discover via WSDL. Most the operations have obvious names, but the complex type fields are often super-abbreviated. The best way to figure which methods to call when is to watch the VS TFS client or TEE with Fiddler or Wireshark or some other HTTP inspection program. TFS VC does do things like file uploads/downloads outside the web services (watch a network trace to see the multi-part MIME upload process and be sure you're sending the right values if you implement this).
A note of caution on the work item tracking web service: this one is going to be extremely hard to master. The WIT design involves the client pre-querying the server for large amounts of schema-less metadata, which is saved on the client (but refreshed incrementally as more web service calls are made). This metadata drives all the client side behavior about work items (what fields are in a work item type, the type of a field, which values are allowed in fields, the rules that run when they change, etc.) and it will take a long time and serious study to build the client behavior to bring a work item to life. Once you have a work item, sending it to the server for update via web services is easy.
It's a lot of work, but it's possible to do incrementally, for example, if you only need some VC features. The TEE team is working on making access from other platforms easier. Please contact Martin Woodward (martin.woodward#microsoft.com) if you have any questions or suggestions in this area.
There is a Java version of the TFS SDK that will run on Linux, Mac, and Windows. It is the SDK that Teamprise uses.
http://blogs.msdn.com/b/bharry/archive/2011/05/16/announcing-a-java-sdk-for-tfs.aspx
Coding directly against the TFS webservices is not supported (even though people have done it). MSFT could break the interface without letting you know in a service pack or other hotfix. Sometimes there aren't other options, but if the Java SDK works for you, I'd try to use that first.
There is good documentation now: https://www.visualstudio.com/integrate/get-started/rest/basics
Google uses the XML/RSS/Atom-based Google Data APIs to provide programmatic access to its various services.
Because it is Google doing this, these API are becoming quite popular, as in: there are many client applications supporting it. Google even provides a lot of client libraries themselves.
It should be possible to use the APIs for other (non-Google) data-sources, as well.
Is anyone doing this?
If I had to provide an API to my calendar web site, would it be a good move to use Google's API instead of CalDAV, which is a "proper" standard but probably more difficult to work with?
Or are the Google APIs too Google-specific, not well documented enough, or inappropriate for some other reason?
For calendaring, the CalDAV protocol and ICS file format are well established and portable between applications and services. I wouldn't try to copy exactly what Google's APIs do, because they can be specific. Offering REST based APIs with XML/Atom support is not terrible choice. Probably all depends on what you're trying to do. For calendaring, CalDAV/ICS are probably the best choice.