I need to use the Bing Maps API to check if a UK postcode (Not sure how different it is for other countries) is valid.
It seems that I can put any nonsense into the field for postcode and I still get a response.
E.G. http://dev.virtualearth.net/REST/v1/Locations/GB/aregsfdgsdfgsdfgdsf?key=BINGMAPSKEYHERE
Gives a result that has a lat and long of 53.9438323974609, -2.55055809020996 in the "point" field, despite that clearly not being a valid postcode.
Is there a way that I can simply test the validity of a postcode?
If you look at the response object for your request you will see a matchCode value. This indicates if the match it is good or not. In this case it says "UpHierarchy" which indicates that it didn't find the exact result so it when up the address hierarchy until it found a result. The result being returned is for the United Kingdom. Additionally, the results also have an entityType value which tells you the type location that was found. In this case it says CountryRegion. You want an entityType value of "PostalCode". By checking these two values you can determine if the returned result is a postal code or not. More details on the geocode response object is documented here: https://msdn.microsoft.com/en-us/library/ff701725.aspx
One thing I would highlight is that the URL format you are using is a bit of a legacy one and isn't as accurate as passing in a single string query (i.e. &q=YOURQUERY). This is highlighted in the best practices docs. If you are using .NET, I hiehgly recommend using the Bing Maps .NET REST toolkit. It makes things really easy and implements best practices for you.
Related
I have the following two API-methods:
1)
#GetMapping("search/findByProjectIds")
public ResponseEntity<List<DailyEntry>> getDailyEntriesFromProjectIds(#RequestParam long[] id) {
return dailyEntryService.getDailyEntriesFromProjectIds(id);;
}
An API-request looks like:
http://localhost:8080/api/dailyEntries/search/findByProjectIds?id=1001&id=1002&id=1003&id=1004
2)
#PatchMapping("/{id}")
public ResponseEntity<?> partialProjectUpdate(#PathVariable List<Long> id, #RequestBody EntryStatus status) throws DailyEntryNotFoundException {
return dailyEntryService.partialDailyEntryUpdate(id, status);
}
An API-request looks like:
http://localhost:8080/api/dailyEntries/1758,1759,1760,1761
That was the recommended way i found of sending multiple IDs for a GET/PATCH request.
Problem: In some cases i have a lot of IDs i want to send. With more data in the future, i might reach the URL character limit at one point. To avoid that, i could be sending the IDs in the Body instead of the URL. The problem is that a) GET doesnt have a body, i would need to use POST for it b) that would break our and the recommended REST-API design.
Is there a better solution?
Is there a better solution?
Not today, no.
GET gives you a couple important elements. One is that it is safe (by definition), another is that general purpose components all share the same understanding of the caching rules.
The only method in the HTTP registry that is close to that is SEARCH, but SEARCH is badly entangled with WebDAV, and isn't generally useful.
A possibility, which may or may not fit your needs, is to think in terms of a URI shortener; you find a resource by POSTING information, and you get redirected to a resource with a simpler identifier that means the same thing. (In effect, the server has a key value store: the key is the identifier, the value is all the junk that you had to put into the POST body).
It's analogous to creating a resource, and then using the identifier for the created resource from that point on. Which restores you to a situation with safe semantics and standard caching, but it isn't as straightforward as the case where all of the interesting things can just be encoded into the URI itself.
GET has querystring length limitation (Refer What is the maximum possible length of a query string?). If you anticipate more id, then better switch it to POST
I am attempting to preview a track via the 7digital api. I have utilised the reference app to test the endpoint here:-
http://7digital.github.io/oauth-reference-page/
I have specified what I consider to be the correct format query, as in:-
http://previews.7digital.com/clip/8514023?oauth_consumer_key=MY_KEY&country=gb&oauth_nonce=221946762&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1456932878&oauth_version=1.0&oauth_signature=c5GBrJvxPIf2Kci24pq1qD31U%2Bs%3D
and yet, regardless of what parameters I enter I always get an invalid signature as a response. I have also incorporated this into my javascript code using the same oauth signature library as the reference page and yet still get the same invalid signature returned.
Could someone please shed some light on what I may be doing incorrectly?
Thanks.
I was able to sign it using:
url = http://previews.7digital.com/clip/8514023
valid consumer key & consumer secret
field 'country' = 'GB'
Your query strings parameters look a bit out of order. For OAuth the base string, used to sign, is meant to be in alphabetical order, so country would be first in this case. Once generated it doesn't matter the order in the final request, but the above tool applies them back in the same order (so country is first).
Can you make sure there aren't any spaces around your key/secret? It doesn't appear to strip white space.
If you have more specific problems it may be best to get in touch with 7digital directly - https://groups.google.com/forum/#!forum/7digital-api
We have a list of address, And trying to get coordinates of them using server side script.
Due to limitation of google map api(2500 query per 24 hour), We move to bing map REST api.
But when we are calling API its not giving the coordinates, While google map api returning the correct coordinates.
Please tell me what i am doing wrong?
Here is the sample call
http://dev.virtualearth.net/REST/v1/Locations?query=A+Beka+Acadamdy,2303+Maravilla,Lompoc,CA,93436,&incl=queryParse&key=MY_API_KEY
if I replace everything with %20 in address then still its not returning data
http://dev.virtualearth.net/REST/v1/Locations?query=A%20Beka%20Acadamdy%202303%20Maravilla%20Lompoc%20CA%2093436&incl=queryParse&key=MY_API_KEY
Another URL is
http://dev.virtualearth.net/REST/v1/Locations?query=103+Black+Men+of+the+Bay+Area+Community,3403+Malcolm+Avenue,Oakland,CA,94607-1407,&incl=queryParse&key=MY_API_KEY
We also tried with this
https://msdn.microsoft.com/en-us/library/ff817004.aspx#sectionToggle6
But sometimes we don't know the country, That's why its not working correctly.
A couple of things to change. First, drop the name of the location, you only need the street address.
So geocoding "2303 Maravilla, Lompoc, CA, 93436" will work.
Secondly, it looks like you are escaping the query value rather than encoding it. Escaping isn't as good as encoding and will result in some queries failing all together. For example if a query had "first & Main" in it, escaping it would not escape the ampersand which would make everything after it a new URL parameter which would likely either cause an error or mean your query is just for "first". By encoding it the ampersand would be changed to %26. This is documented in the best practices here: https://msdn.microsoft.com/en-us/library/dn894107.aspx
By encoding your query parameter your address will look like this:
"2303%20Maravilla,%20Lompoc,%20CA,%2093436"
Why is it when I request some postcodes from Bing maps I get an incorrect coordinates
http://dev.virtualearth.net/REST/v1/Locations?postalCode=IM1+1LD&countryRegion=GB&o=xml&key=MY_BING_KEY
While when I request it using this I get the correct ones
http://dev.virtualearth.net/REST/v1/Locations?postalCode=IM1&1LD&countryRegion=GB&o=xml&key=MY_BING_KEY
i.e. when I send IM1+1LD as a postalcode incorrect results are returned, while sending IM1&1LD returns the correct results in the response.
The + indicates your are escaping rather than encoding your query. The plus should be %20 instead. Also, in the UK postal codes are a special case. I recommend searching for them using a query search instead like this: http://dev.virtualearth.net/REST/v1/Locations?q=IM1%201LD&o=xml&key=YOUR_KEY
You can find additional tips on use the REST services here: https://blogs.bing.com/maps/2013/02/14/bing-maps-rest-service-tips-tricks
Given:
/images: list of all images
/images/{imageId}: specific image
/feed/{feedId}: potentially huge list of some images (not all of them)
How would you query if a particular feed contains a particular image without downloading the full list? Put another way, how would you check whether a resource state contains a component without downloading the entire state? The first thought that comes to mind is:
Alias /images/{imageId} to /feed/{feedId}/images/{imageId}
Clients would then issue HTTP GET against /feed/{feedId}/images/{id} to check for its existence. The downside I see with this approach is that it forces me to hard-code logic into the client for breaking down an image URI to its proprietary id, something that REST frowns upon. Ideally I should be using the opaque image URI. Another option is:
Issue HTTP GET against /feed/{feedId}?contains={imageURI} to check for existence
but that feels a lot closer to RPC than I'd like. Any ideas?
What's wrong with this?
HEAD /images/id
It's unclear what "feed" means, but assuming it contains resources, it'd be the same:
HEAD /feed/id
It's tricky to say without seeing some examples to provide context.
But you could just have clients call HEAD /feed/images/{imageURI} (assuming that you might need to encode the imageURI). The server would respond with the usual HEAD response, or with a 404 error if the resource doesn't exist. You'd need to code some logic on the server to understand the imageURI.
Then the client either uses the image meta info in the head, or gracefully handles the 404 error and does something else (depending on the application I guess)
There's nothing "un-RESTful" about:
/feed/{feedId}?contains={imageURI}[,{imageURI}]
It returns the subset as specified. The resource, /feed/{feedid}, is a list resource containing a list of images. How is the resource returned with the contains query any different?
The URI is unique, and returns the appropriate state from the application. Can't say anything about the caching semantics of the request, but they're identical to whatever the caching semantics are of the original /feed/{feedid}, it simply a subset.
Finally, there's nothing that says that there even exists a /feed/{feedid}/image/{imageURL}. If you want to work with the sub-resources at that level, then fine, but you're not required to. The list coming back will likely just be a list of direct image URLS, so where's the link describing the /feed/{feedid}/image/{imageURL} relationship? You were going to embed that in the payload, correct?
How about setting up a ImageQuery resource:
# Create a new query from form data where you could constrain results for a given feed.
# May or may not redirect to /image_queries/query_id.
POST /image_queries/
# Optional - view query results containing URIs to query resources.
GET /image_queries/query_id
This video demonstrates the idea using Rails.