I am reading the Google Vision API documentation:
(https://cloud.google.com/vision/docs/requests-and-responses)
It says something like the follwing:
Currently, the Vision API consists of one collection (images) which supports one HTTP Request method (annotate):
POST https://vision.googleapis.com/v1/images:annotate
My question is what does it mean by the method "annotate"? Also, how do I read this syntax with the colon ":"? Is this just a notation that Google uses or some kind of industry standard where you use the colon and calling the stuff after a "method"?
I am a financial Java developer but noob to Web/HTTP technology (I have read some basic of GET/POST but that did not seem to help me with this question). If it seems to you that I am totally lacking in some fundamentals, is there any pointer for me to read up some related books/website/tutorial/documentation that can help me understand this better? Any help is appreciated!
Related
since google did not create extensive documentation for their API Linter and I cannot find anything from other sources, i wanted to ask here.
From what exactly am i supposed to create protofiles and what do they represent?
As I understood, these protofiles get checked for compliance to their AIPs.
I'm interested in creating a automatic prototype (Java) to check for customized API Rules and am thinking about using Protobufer for this goal. Would this be a pragmatic solution?
Thank you!
As I now understand, Googles API Linter isn't supposed to check a API or a different API specification for compliance.
It checks proto files because they are themself the API specification and can be converted to Code. But before converting them they can be checked against rules they have to comply with.
These rules are not in the protofiles (as I initially thought) but in the many GO-files under rules/ .
Please correct me if you read this and find mistakes! Thanks!
Summarize the problem:
Being relatively new to Ruby/Gems and developing in general, some concepts evade me
I'm learning about the google-api-client Gem, and am attempting to understand the Basic Usage, and want to know how a developer knows which class to use, when instantiating an ojbect, during the "aliasing of the module" portion:
To use an API, include the corresponding generated file and instantiate the service. For example to use the Drive API:
require 'google/apis/drive_v2'
Drive = Google::Apis::DriveV2 # Alias the module
drive = Drive::DriveService.new # why is ::DriveService used here?
#etc
Describe what I've tried:
I've searched through the reference documentation for the google-api-client for a clue about the "decision" to instantiate drive with ::DriveService.new
The best reason I've come up with is: DriveService is instantiated because it is the "BaseService" of the "DriveV2" Class.... but I'm reaching for straws with this logic.
My specific question is:
How does a developer using APIs and this Google-API-client Gem know which object to instantiate?
I have to imagine there's a more elegant "way" to determine which object to instantiate at this point of accessing an API than digging through the documentation of the Gem....I mean...the "BaseService" information is coming from the documentation for this specific Gem.....
Maybe this is a matter of me losing "scope" per say by the Google API and the ambiguously named Gem maintained by Google...
But then again...if I'm using this Gem...then this documentation would always apply, because I wouldn't be able to use this Gem if it wasn't a Google-API....
from the documentation
The link above is the necessary detail regarding Authorization for an API key.
If you're like me, and this subject is new to you, there are three topics that you need to understand:
Authentication
Authorization
Accounting
The documentation for the google-api-client gem is robust enough to answer a lot of questions, however, my answer here is hopefully enough to get you pointed in the right direction.
I'm leaving the question up, in case anyone else needs some guidance regarding this same subject.
Looks like google has deprecated a bunch of place types from their places API:
https://developers.google.com/places/web-service/supported_types
"The following types are deprecated, and will continue to be supported until February 16, 2017: establishment, finance, food, general_contractor, grocery_or_supermarket, health, place_of_worship."
I wasn't able to figure out what the new replacement types would be. "food" and "store" are too generic for a grocery related store.
Additionally, the documentation states that these types are deprecated only for the query API. The place-details results "may" still contain them.
A workaround I can implement is to fetch the places using a more generic type (e.g., store), and then filter on my end.. not ideal, but out of ideas. However, this also means that I'll rely on the more granular type (e.g., grocery_or_supermarket) to be mentioned in the response.
Can someone pls comment or share ideas on this issue? (did any of you have to deal with this? would be great if you can share your thoughts)
Thanks
Use Foursquare API for this data instead of Google, just get a Foursquare API key, check the API how to use details online and that should provide the data your need.
I am currently evaluating possibilities, how to write/generate level2+ rest API. I came across karharis and i pretty like the concept and the whole idea how its done seems sound to me. But I have not found answers to these questions:
How to handle security properly. I can imagine that it might get tricky, as JSON api supports traversing to some extent. (out app will run in spring environment, so I suppose that we might use spring-security, but I do not know, if we will encounter some hidden traps)
API versioning. I havent found any clues how to handle API evolution. Are there any already supported options (content negotiation, path variable, query parameter...?) or do we need to hack it ourselves?
Thanks in advance!
I'm working with some legacy exchange code and I am having trouble finding information about some methods/constants. A google search reveals others using similar code, but with no explanations. Does anyone have any ideas where I can find proper docs? One constant I am looking for is: SYNC_ASSOCIATED.
Exchange is a Microsoft protocol, so the best place to look is usually MSDN.
The MSDN library, however, seems curiously lacking on Exchange documentation, but an MSDN search looks in a few other places too.
In this case, it's led me to this blog post which gives you a number of constants as they would be defined in a C header file. SYNC_ASSOCIATED is defined as 0x10.
This is part of ICS, Exchange's mechanism for monitoring and tracking changes in a mailbox. See the ICS section of the bulk data transfer protocol spec.