I'm using the Google Places API endpoint "findplacefromtext" and tried a search similar to the example.
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=mongolian%20grill&inputtype=textquery&fields=photos,formatted_address,name,opening_hours,rating&locationbias=circle:2000#47.6918452,-122.2226413&key=YOUR_API_KEY
However, when you use this it only ever returns one result. There is a cafe near me that's called "Cream" but when you pass that as the "input" parameter it returns shops that have a category of "Ice Cream". I thought it should only search the name of the business.... If I can't find the place by name does it search the category type as a fall back? When I execute the same search in Google Maps it returns the same data but I get multiple results and I can see the place I am trying to retrieve 3rd on the search result list.
Is it possible to make it return more than one result? The documentation doesn't mention anything about this.
I believe what you need is the Text Search request. The Find Place request is meant for exact addresses.
The Google Places API Text Search Service is a web service that
returns information about a set of places based on a string — for
example "pizza in New York" or "shoe stores near Ottawa" or "123 Main
Street". The service responds with a list of places matching the text
string and any location bias that has been set.
The service is especially useful for making ambiguous address queries
in an automated system, and non-address components of the string may
match businesses as well as addresses. Examples of ambiguous address
queries are incomplete addresses, poorly formatted addresses, or a
request that includes non-address components such as business names.
Taken from https://developers.google.com/maps/documentation/places/web-service/search#TextSearchRequests
Related
I am developing an API in a microservice for Invoice entity that takes in input a list of Purchase Order Item (i.e. PO Item) identifiers for ex. PO# + productIdentifier together can be used to identify a POItem uniquely. The response of the API is the invoiced quantity of each PO Item.
Input Model -
input GetInvoicedQuantityForPOItemsRequest {
poItemIdentifierList : POItemIdentifierList
}
Structures
list POItemIdentifierList {
member : POItemIdentifier
}
structure POItemIdentifier {
purchaseOrderNumber : String,
productIdentifier : Long
}
Invoiced Quantity of a POItem = SUM of Quantity of Invoice Items created from that PO Item.
Note : A single PO can be used to create multiple Invoices. An Invoice can be created from multiple POs.
I am quite new to REST and so far we have been using RPC endpoints in our legacy service. But now i am building a new service where i am defining endpoints in REST format (for ex. CreateInvoice has been changed to POST /invoice) and I need some suggestions from Stack Overflow community what would be the right approach for defining the REST endpoint of this API or should we keep it in RPC format itself.
RPC endpoint for this API in legacy system : POST /getInvoicedQuantityForPOItems
Our first attempt on REST for this is : POST /invoice/items/invoicedQuantityForPOItems. But this URI does not look like a Noun it is a Verb.
this URI does not look like a Noun it is a Verb.
REST doesn't care what spelling conventions you use for your resource identifiers.
Example: this URI works exactly the same way that every other URI on the web works, even though "it looks like a verb"
https://www.merriam-webster.com/dictionary/post
The explanation is that, in HTTP, the semantics of the request are not determined by parsing the identifier, but instead by parsing the method token (GET, POST, PUT, etc).
So the machines just don't care about the spelling of the identifier (besides purely mechanical concerns, like making sure it satisfies the RFC 3986 production rules).
URI are identifiers of resources. Resources are generalizations of documents. Therefore, human beings are likely to be happier if your identifier looks like the name of a document, rather than the name of an action.
Where it gets tricky: HTTP is an application protocol whose application domain is the transfer of files over a network. The methods in HTTP are about retrieving documents and metadata (GET/HEAD) or are about modifying documents (PATCH/POST/PUT). The notion of a function, or a parameterized query, doesn't really exist in HTTP.
The usual compromise is to make the parameters part of the identifier for a document, then use a GET request to fetch the current representation of that document. On the server, you parse the identifier to obtain the arguments you need to generate the current representation of the document.
So the identifier for this might look something like
/invoicedQuantityForPOItems?purchaseOrder=12345&productIdentifiers=567,890
An application/x-www-form-urlencoded representation of key value pairs embedded in the query part of the URI is a common spelling convention on the web, primarily because that's how HTML forms work with GET actions. Other identifier conventions can certainly work, though you'll probably be happier in the long term if you stick to a convention that is easily described by a URI template.
This question here basically asks the same question:
Restrict Google Places Autocomplete to return addresses only
But doesn't get the right answer.
If we look at the official documentation examples they have an option to selected address type. However, on it, we can see that it will allow us to selected just streets:
Is there a way to make Places Autocomplete select real addresses only?
Since this question is quite old, the search result is now somehow different but the fact that address type returns street addresses remains the same.
And to clarify things here, the API is working as intended when it returns street addresses.
types=address seems to be quite vague and what you need to do is to be more specific if you don't want street address to be included.
Here's a table for reference on the different types of restrictions for autocomplete from the Place Types Documentation.
Table 3: Type collections supported in Place Autocomplete requests
The supported types are:
geocode instructs the Place Autocomplete service to return only geocoding results, rather than business results. Generally, you use this request to disambiguate results where the location specified may be indeterminate.
address instructs the Place Autocomplete service to return only geocoding results with a precise address. Generally, you use this request when you know the user will be looking for a fully specified address.
establishment instructs the Place Autocomplete service to return only business results.
(regions) type collection instructs the Places service to return any result matching the following types:
locality
sublocality
postal_code
country
administrative_area_level_1
administrative_area_level_2
(cities) type collection instructs the Places service to return results that match locality or administrative_area_level_3.
To further prove this, I tried using the official documentation example for testing.
I tried searching real street address with both types=address and types=geocode and they return street addresses as expected.
With address type:
With geocode type:
Then I tried the types=establishment and it did not return any street addresses.
With establishment type:
You can use any other types value apart from types=establishment like the (cities) and (regions). As long as you are specific in your restrictions, things will be working fine. You can just put some toggle on your app to change restrictions just like on the official docs example so that your end user could freely choose the restrictions. But it still depends on your use case.
Hope this helps.
FHIR stu3
tried this:
http://fhirtest.uhn.ca/baseDstu3/PlanDefinition/20630?_revinclude=ActivityDefinition
based on the example from :
http://build.fhir.org/search.html#include
but it returned 400 Bad Request
thanks
There are 4 issues with your syntax:
_revinclude is a parameter for the search operation. Searches use the "type" endpoint (i.e. [base]/[resource]). Your format is for a read ([base]/[resource]/[id]). Reads only return a single resource, not a bundle and they don't take most parameters (you can do _format, but that's about it)
_revinclude needs to identify both the resource and the search parameter. E.g. ActivityDefinition:plandefinition, not just ActivityDefinition
The reference in the resources isn't from ActivityDefinition to PlanDefinition, but from PlanDefinition to ActivityDefinition. So you don't actually need a reverse-include. A simple _include is what you need given that your focus is already PlanDefinition
There's no standard search parameter on PlanDefinition to search based on ActivityDefinitions - and both _include and _revinclude are based on search parameters (because that's what servers index).
Because of the 4th issue, you're not going to be able to execute this test against any of the public test servers - unless you make special arrangements, they only support core search criteria. However, on your own system, you're free to define your own search criteria. If you were to do that, you ought to be able to make the query work using the following url:
[base]/PlanDefinition?_id=20630&_include=activitydefinition
(Assuming that you've named your custom search criteria having a path of PlanDefinition.activity.activityDefinition as having a name of "activitydefinition")
On the request for current place I receive a list of places. Every place has an address but that address is a string so I can't get only the country name.
Could someone help me on this matter?
Country is only explicitly available when using the Place Details API, not the Places API. (https://developers.google.com/maps/documentation/places/web-service/details)
You first need to look up a place_id for the specific place you're looking for. You then use your place_id to pull details from the Details API, which includes information like:
Fully formatted address, including country
Address components
Sample reviews
Phone # and website
Operating hours
If you have read the Google Places Autocomplete doc,you must know about API properties.you can use the type as '(region)' and will return you many results (plus country).And if you look inside address_components field (it's array with dynamic length),you will see,that the last item of array is what you need.Here is a great page to read a correct doc and try examples yourself.
http://www.w3docs.com/learn-javascript/places-autocomplete.html
When I call communityService.getMyCommunities(params) or communityService.getPublicCommunities(params) or communityService.getSubCommunities(parentCommunity, params) I would expect that filling params with e. g. tags=[mytag,yourtag] the call would only lookup communities having at least one of these tags (or both, however).
But to me it looks like this param ("tags") is simply ignored, and I always receive all communities of the given category (my / public / sub).
In case of having lots of communities of the requested category this massively slows down performance when I only want to retrieve communities with e. g. one certain tag: I receive all data over the net and must filter / lookup the received object list locally.
What am I doing wrong?
Is there something missing in the SDK implementation?
As part of the communities/my api, you cannot do any filtering... you need to use Search APIs.
In order to get a filtered list of communities based on the tags, you need to make a request to the following URL.
https://apps.na.collabserv.com/search/atom/mysearch?scope=personalOnly&scope=communities&query=&constraint={%22type%22%3A%22category%22%2C%22values%22%3A[%22Tag%2Fprb%22]}&page=1&pageSize=10
Yes, it is URL encoded, you can then change prb to match your tag, and you can repeat the constraints for each tag
You can also reference Link to Search API Constraints