I need to be able to look up a location based on an exact city, state, and country triplet.
HERE's Geocoder v6.2 API supports exact matching out of the box, however that API is in maintenance mode and I would prefer to be on the latest and greatest given I'm starting a project from scratch.
Here's some examples: You can hit the Geocoder v6.2 API with a request including a fake city and get the correct response (no results):
https://geocoder.ls.hereapi.com/6.2/geocode.json?apiKey=...&country=USA&state=TX&city=Faketown
{
"Response": {
"MetaInfo": {
"Timestamp": "2021-02-12T01:53:40.367+0000"
},
"View": []
}
}
but what I believe is an equivalent request to the GS v7.0 API returns incorrect results when using the "qualified query" syntax:
https://geocode.search.hereapi.com/v1/geocode?apiKey=...&qq=country=USA;state=TX;city=Faketown
{
"items": [
{
"title": "Laketown, UT, United States",
"id": "here:cm:namedplace:21035617",
"resultType": "locality",
(Wrong city, wrong state, correct country).
What do you need to do to get the v7 API (geocode or otherwise) to use exact matching and thus return zero results for this request? Or should I use the Geocoder v6.2 API for this instead?
Geocoder v7 API Documentation states the following information.
The /geocode endpoint is used to find the geo-coordinates of a known address, place, locality or administrative area, even if the query is incomplete or partly incorrect. It also returns a complete postal address string and address details.
This is the reason behind the behavior, you can check the following link for more information.
https://developer.here.com/documentation/geocoding-search-api/dev_guide/topics/endpoint-geocode-brief.html
We can recommend you to opt for /Autocomplete which provides completion of the entered keystrokes to the valid addresses, where no spell correction is included.
For more information you can check the following link.
https://developer.here.com/documentation/geocoding-search-api/dev_guide/topics-api/code-autocomplete-examples.html
For hands on experience you can also check the following link.
https://tcs.ext.here.com/examples/v3/admin_boundaries_batch
Related
I am using AWS Javascript SDK to validate phone number, the payload is like this
{
"IsoCountryCode": "string",
"PhoneNumber": "string"
}
In the docs, its mentioned that providing a country code in PhoneNumber field is mandatory, which is clear. But I didn't understand the purpose of providing IsoCountryCode. I tried running the api without this field and the response isn't different.
What purpose does it serve? is it even mandatory?
I tested with the AWS SDK for Java V2. In the Javadocs - it is defined as:
The two-character code, in ISO 3166-1 alpha-2 format, for the country or region where the phone number was originally registered.
However, this value does not seem to be required to make the call. As you can see below in my screen shot, i commented out this value and the call was successful. As you can see, I got back information about my number such as the carrier, etc.
I called the following http request to the Geocoding endpoint of the Here API, with a free form address entry and language parameters, such as:
https://geocode.search.hereapi.com/v1/geocode?q=Tubdispanser+2+Belarus&lang=en-US&apiKey={API_KEY}
The parameters are:
The address: q = "Tubdispanser 2 Belarus"
Language: lang = "en-US"
The API response is the following:
{"items":[{"title":"Тубдиспансер 2, Minski rayon, Minskaya voblasts', Belarus","id":"here:af:streetsection:KRpXCVKK0uoNU4Le3JvXDD:CggIBCCU4sPZAhABGgEyKGQ","resultType":"houseNumber","houseNumberType":"PA","address":{"label":"Тубдиспансер 2, Minski rayon, Minskaya voblasts', Belarus","countryCode":"BLR","countryName":"Belarus","state":"Minskaya voblasts'","county":"Minski rayon","city":"Minski rayon","street":"Тубдиспансер","houseNumber":"2"},"position":{"lat":53.9567,"lng":27.64356},"access":[{"lat":53.95679,"lng":27.6433}],"mapView":{"west":27.64203,"south":53.9558,"east":27.64509,"north":53.9576},"scoring":{"queryScore":1.0,"fieldScore":{"streets":[1.0],"houseNumber":1.0}}}]}
The result is different from the one given by Here We Go online browser. Does Here We Go browser use a different endpoint?
Thank you.
Given the additional information provided by OP in comments, it appears that the location returned by HERE WeGo webapp refers to the same place as the result from the Geocode API with, notably, the following differences:
The coordinates decimal precision slightly differs
The address is formatted differently, e.g. the result from the geocoder also contains the "region" information (voblast of Minsk)
The reason of this differences is that, as #leopectus hinted, the search from the HERE WeGo webapp actually uses the *Places Autosuggest API. It uses the following endpoint:
https://places.api.here.com/places/v1/autosuggest
HERE WeGo may use a different version of the API as well as additional parameters. As such you may not always get the exact same results.
I am using Google's Geocoding API using the component filtering.
To validate the zip code in a specific country I use the following call for example:
https://maps.googleapis.com/maps/api/geocode/json?components=postal_code:94301|country:USA
I want to add another component to indicate the state. According to the documentation I can do it using the "administrativeArea".
I couldn't get it to work.
For example, calling the API with the zip code 94301 and state "Arizona" should return with no values, while the state "California" should return the relevant address.
I tried:
https://maps.googleapis.com/maps/api/geocode/json?components=postal_code:94301|country:USA|administrativeArea=Arizona
You are using administrativeArea=Arizona in components filtering. Please note that web service should use administrative_area=Arizona according to the documentation.
https://developers.google.com/maps/documentation/geocoding/intro#ComponentFiltering
The following components may be used to influence results, but will not be enforced:
route matches the long or short name of a route.
locality matches against locality and sublocality types.
administrative_area matches all the administrative_area levels.
When I execute the following request
https://maps.googleapis.com/maps/api/geocode/json?components=administrative_area%3AArizona%7Cpostal_code%3A94301%7Ccountry%3AUS&key=MY_API_KEY
I get the response
{
"results":[
],
"status":"ZERO_RESULTS"
}
You can also see this in Geocoder tool:
https://developers-dot-devsite-v2-prod.appspot.com/maps/documentation/utils/geocoder/#in_administrative_area%3DArizona%26in_postal_code%3D94301%26in_country%3DUS%26options%3Dtrue
https://developers-dot-devsite-v2-prod.appspot.com/maps/documentation/utils/geocoder/#q%3D%26in_country%3DUS%26in_administrative_area%3DCalifornia%26in_postal_code%3D94301
I hope this helps!
I'm in the process of creating a REST API. Among others, there is a resource-type called company which has quite a lot of attributes/fields.
The two common use cases when dealing with company resources are:
Load a whole company and all its attributes with one single request
Update a (relatively small) set of attributes of a company, but never all attributes at the same time
I came up with two different approaches regarding the design of the API and need to pick one of them (maybe there are even better approaches, so feel free to comment):
1. Using subresources for fine-grained updates
Since the attributes of a company can be grouped into categories (e.g. street, city and state represent an address... phone, mail and fax represent contact information and so on...), one approach could be to use the following routes:
/company/id: can be used to fetch a whole company using GET
/company/id/address: can be used to update address information (street, city...) using PUT
/company/id/contact: can be used to update contact information (phone, mail...) using PUT
And so on.
But: Using GET on subresources like /company/id/address would never happen. Likewise, updating /company/id itself would also never happen (see use cases above). I'm not sure if this approach follows the idea of REST since I'm loading and manipulating the same data using different URLs.
2. Using HTTP PATCH for fine-grained updates
In this approach, there are no extra routes for partial updates. Instead, there is only one endpoint:
/company/id: can be used to fetch a whole company using GET and, at the same time, to update a subset of the resource (address, contact info etc.) using PATCH.
From a technical point of view, I'm quite sure that both approaches would work fine. However, I don't want to use REST in a way that it isn't supposed to be used. Which approach do you prefer?
Do you really nead each and every field contained in the GET response all the time? If not, than its more than just fine to create own resources for addresses and contacts. Maybe you will later find a further use-case where you might reuse these resources.
Moreover, you can embed other resources as well in resources. JSON HAL (hal-json) f.e. explicitely provides an _embedded property where you can embed the current state of f.e. sub-resources. A simplified HAL-like JSON representation of an imaginary company resource with embedded resources could look like this:
{
"name":"Test Company",
"businessType":"PLC",
"foundingYear": 2010,
"founders": [
{
"name": "Tim Test",
"_links": {
"self": {
"href": "http://example.org/persons/1234"
}
}
}
],
...
"_embedded": {
"address": {
"street": "Main Street 1",
"city": "Big Town",
"zipCode": "12345",
"country": "Neverland"
"_links": {
"self": {
"href": "http://example.org/companies/someCompanyId/address/1"
},
"googleMaps": {
"href": "http://maps.google.com/?ll=39.774769,-74.86084"
}
}
},
"contacts": {
"CEO": {
"name": "Maria Sample",
...
"_links": {
"self": {
"href": "http://example.org/persons/1235"
}
}
},
...
}
}
}
Updating embedded resources therefore is straigtforward by sending a PUT request to the enclosed URI of the particluar resource. As GET requests my be cached, you might need to provide finer grained caching settings (f.e. with conditional GET requests a.k.a If-Modified-Since or ETAG header fields) to retrieve the actual state after an update. These headers should consider the whole resource (incl. embedded once) in order to return the updated state.
Concerning PUT vs. PATCH for "partial updates":
While the semantics of PUT are rather clear, PATCH is often confused with a partial update by just sending the new state for some properties to the service. This article however describes what PATCH really should do.
In short, for a PATCH request a client is responsible for comparing the current state of a resource and calculating the necessary steps to transform the current resource to the desired state. After calculating the steps, the request will have to contain instructions the server has to understand to execute these instructions and therefore produces the updated version. A PATCH request is furthermore atomic - either all instructions succeed or none. This adds some transaction requirements to this request.
In this particular case I'd use PATCH instead of subresources approach. First of all this isn't a real subresources. It's just a fake abstraction introduced to eliminate the problem of updating the whole big entity (resource). Whereas PATCH is a REST compatible, well established and common approach.
And (IMO ultima ratio), imagine that you need to extend company somehow (by adding magazine, venue, CTO, whatever). Will you be adding a new endpoint to enable client to update this newly-added part of a resource? How it finishes? With multiple endpoint that no one understands. With PATCH your API is ready for new elements of a company.
Trying to figure out the correct Json string to pass to my OpenGraph app. I'm using the Gigya Java SDK, but decided to eliminate some of the extra layers in testing the string.
So I'm first of all looking at the Graph API Explorer.
My POST field name is "Recipe" and the value is
{"title":"one-handed fried pies","description":"ye olde Description goeth here.","image":"http://www.recipe.com/images/one-handed-fried-pies-R094255-ss.jpg","url":"http://www.recipe.com/one-handed-fried-pies/"}
This maps exactly to the fields of the Recipe object.
However, no matter how I format the JSON, I get this exception
{
"error": {
"message": "(#3503) \"{\"title\":\"one-handed fried pies\",\"description\":\"ye olde Description goeth here.\",\"image\":\"http://www.recipe.com/images/one-handed-fried-pies-R094255-ss.jpg\",\"url\":\"http://www.recipe.com/one-handed-fried-pies/\"}\" is an invalid value for property \"recipe\" with type \"Reference\"",
"type": "OAuthException",
"code": 3503
}
}
Any thoughts?
By hacking thru, got it to work this way.
Most important... the URL as above must point to a page that has valid og: tags for the app. (You can look at the source of this page for the structure http://www.csmonitor.com/Science)
In the Graph Api Explorer,Select your Application in the top left.
Click get Access token.
Select POST.
Click on Add a field
Type the name of the object. In my case "recipe".
Type the url. In my case, I set up a live test page and deployed it.
click submit and wait for an id.
{
"id": "290473937742173"
}