I can see no advantage in using the Server-side Geocoding Web Service when Google Maps provides a full featured Client-side Geocoding API for JavaScript.
First of all, this automatically solves your same-origin problem, and in addition the request limits would be calculated per client IP address instead of of per server IP address, which can make a huge difference for a popular site.
Here's a very simple example using the JavaScript Geocoding API v3:
<script src="http://maps.google.com/maps/api/js?sensor=false"></script>
<script type="text/javascript">
var geocoder = new google.maps.Geocoder();
var address = 'London, UK';
if (geocoder) {
geocoder.geocode({ 'address': address }, function (results, status) {
if (status == google.maps.GeocoderStatus.OK) {
console.log(results[0].geometry.location);
}
else {
console.log("Geocoding failed: " + status);
}
});
}
</script>
If for some reason you still want to use the server-side web-service, you could set up a very simple reverse proxy, maybe using mod_proxy if you are using Apache. This would allow you to use relative paths for your AJAX requests, while the HTTP server would be acting as a proxy to any "remote" location.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically use it as follows:
ProxyPass /geocode/ http://maps.google.com/maps/api/geocode/
In this case, the browser could make a request to /geocode/output?parameters
but the server would serve this by acting as a proxy to http://maps.google.com/maps/api/geocode/output?parameters
.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…