I am designing a geo-location based application and facing the next issues:
Having the location of the user at the moment I simply need to send request to google Places API to get the related establishments using:
https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=30.26989954982109,-97.73595370200533&radius=100&types=bar&key=myAPIKey
I hate to admit, but it is my first time I face the Cross-Origin-Resource-Sharing and most of the things that are published here regarding CORS don't make sense to me, also the documentation for the API is not very helpful to me since it lacks examples. I would greatly appreciate if anyone could give a descend step-by step explanation how to send requests across domains to retrieve JSON.
At the time of this writing Google Places API does not seem to support CORS. A work around is to enable proxy in your web server. For example, in ngnix, create a new location:
location /maps/ {
proxy_pass https://maps.googleapis.com/maps/;
}
Then, instead of sending an XmlHttpRequest to Google API, send it to your own web server.
Related
i'm keen to understand if i can use a google sheet / script to receive incoming data from an external (3rd party / non google) webhook.
the webhook requirements:
a defined / expected method from POST (my preferred), PUT, PATCH
an endpoint to post to which, if this is possible, i assume would be something like https://docs.google.com/spreadsheets/d/[sheet_id]/[service_name] or even https://script.google.com/d/[project_id]/[service_name] where ScriptApp can perform handling of the data
method of authentication; the current options available from the sending system are "none" or "oauth"
incoming content; the body is a simple { "id": integer }
oauth inputs include authentication_url, azure_subscription_key, app_key, app_secret, resource_id.
hopefully this is enough information to determine if this is possible. if not then please comment with questions and i'll do my best to answer them. thanks in advance :)
Short answer: Yes, for the most part.
Explanation -
...receive incoming data from an external (3rd party / non google) webhook.
Google Apps Script (GAS) provides a format called as Web Apps where, you write a script to handle incoming requests and "deploy" the Apps Script itself as a web app. In doing so, GAS provides you with it's own endpoint.
Adding this as a point of clarification where the endpoint/URL would not be that of a 3rd party, but that of GAS itself, which will need to be used in a 3rd party's application where they require you to provide an endpoint :)
You only have GET & POST requests (as of now) that can be handled by Apps Script's Web App and not the others that you've stated.
The non-dev, prod-ready link would look something like this - https://script.google.com/macros/s/Unique-Script-ID-Goes-Here/exec
The available auth/permission settings are described here.
The request parameters also describes the format of data that can be processed by the Web App.
Hope this helps but please feel free to ask for any clarifications too, as required.
I'm a trainee and am learning about Flex, so I'm a total noob at this... My boss asked me to research the calDAV protocol for us to use in a calendar app we already have. I was trying to understand the Google API but I have no clue how to put this in our code. He wants me to make it possible to share events added to our calendar in Google Calendar or IPhone, for example. I'm starting to get desperate :(
It appears as the Google CalDAV API is deprecated and it will likely go offline at some point soon.
Edit: The Google CalDAV API is not being deprecated, only the previous endpoint. Wording below has been amended to recommend Google's own API as an alternative method.
CalDAV itself is basically just a way to format information about calendar events in a specific way for communicating between services. It also defines how to send and receive this information. Here's the CalDAV specification for more info.
If the requirement is to work with Google Calendar but not specifically with CalDAV, you could look at v3 of their API. It appears to be based more around JSON which should make it slightly easier to work with in AS3. There appears to be AS3 libraries out there for Google Calendar, but they seem to be outdated and unsupported, so it's likely that they won't work with the latest versions of the API.
The Google API relies on REST calls. It basically means that you send HTTP GET, POST, DELETE etc requests to specified URLs on Google's servers to do specific tasks or to request data.
In order to use the API you need to authorize your requests. The most common way to do this is to use OAuth 2.0 - in which your user grants your application access to its Google account, and in turn your application receives a token that needs to be sent with each request.
This isn't a complete answer to your problem, but I hope it outlines the process and gives you some useful links to read.
While creating the Client_ID I am stuck in these two textboxes (JavaScript Origins and Authorized Redirect URLs) appearing on that PopUp. I am not able to search the internet about those two things.
In a tutorial it was written that we just need to put our hostnames there! But why? What do they actually mean?
Hope I am clear.
Any help would be appreciated.
If you're using the JavaScript client, you need to set a valid JavaScript origin for us to authorize you.
Authorized redirect URIs are the endpoints we're going to call as a callback if you're using 3-legged OAuth 2.0 flow. https://developers.google.com/accounts/docs/OAuth2#webserver illustrates a sequence where Google endpoints pushes a code to your application. Push is done by calling a redirect url with a code query parameter.
http://yoursite/callback?code=[code to exchange]
The answer posted here https://stackoverflow.com/a/10486729/1919484 references an 'instant mode' box.com api authentication option that 'gets you an authentication token via the /tokens V2 API endpoint, but limits you to accessing a single folder in the user's account.'
I've googled around for such a thing but I can't find any more info about it. It seems like exactly what I need for an app I'm working on.
Can anyone shed any light on whether such a thing is still in the works, or if it has been canceled or replaced?
Many thanks in advance.
Instant Mode is a beta feature that we're still testing/iterating on. It's not ready for production applications at this time, but you can email us at API at box.com with your use case so we can let you know when it's ready.
I am an android application developer (trying to be one) and I want to learn how to communicate with web sites from my applications. However, I don't know where to start. Can you point me in the right direction?
PS : I believe "web communcation standarts" is wrong term but i don't know how to call them.
I'd suggest that you learn by doing. Pick an idea - let's say you want to upload a picture from your Android phone to facebook.
Now go and research how to do that. Facebook exposes what they call the "Graph API" for all fb resources, including users, statuses, and photos, among other things. The Graph API is a REST API - in other words each item on the backend is modelled as a "resource" which is accessible from a URL. (Learn more about REST on wikipedia). Send a GET HTTP message to the given URL and you can get information on the resource. Send a POST to the container of that resource, and you can add another of whatever it is. In this model, to add a photo, you POST to the album URL. Read on FB for how to do that. They call it "publishing".
But reading that doc page you learn that in order to POST you need an authorization token.
Your app needs publish_stream permissions. How do you get that? Keep reading in the FB doc and you'll see a link to the Authentication and authorization guide. That tells you about how to use OAuth 2.0 in Facebook apps.
Your app will send its first feeble message out, and get an error response. Why? You'll want to examine the message. so you google and figure out that you can use an http debugging proxy to help you, something like Fiddler2 for Windows, or Charles for other systems. So you download that, set the proxy on your Android device, and now you can view outgoing HTTP messages and their responses on your PC.
Keep plugging along, learning what you need to accomplish the task in front of you: in this example, posting a photo from an android device to Facebook.
After you reach that goal, you will have learned quite a bit of practical knowledge for this domain of problem. Then you can try a new goal, and work on that.
After a few iterations of this, you will have learned how to learn, which is even better than learning REST or OAuth. If you know how to learn, the sky's the limnit.
Learn about HTTP first. There is far more to HTTP than there first appears. It is a building block for everything on the web.
You will not go wrong by getting very familiar with this http://www.w3.org/Protocols/rfc2616/rfc2616.html