Is it possible to search for users which are beyond my immediate circle using FB graph API?
If not, does having a paid subscription account help to overcome this hurdle?
I'm using following graph query but seems to be restricted within my circle:
https://graph.facebook.com/search?q=xx+yy&limit=5000&type=user&access_token=*
Also if I increase the offset using pagination in the next call, It will still returns the same set of user IDs. So not sure if I'm passing the parameters incorrectly or missing some other parameters.
Thanks for all your help in advance!
Not sure what you mean by your immediate circle in terms of Facebook but I assume you mean your friends. The Graph API allows you to search for all public objects (source) - this means every person (according to answers on this page since names are always publicly available - that's my understanding), not only people who you are friends with on Facebook.
Hence, when you're searching for "John" you should get everyone called John if you're using the Graph API correctly - make sure your access token is valid (you do not need any special permissions to search for people) and your syntax follows the example from here.
In order to test your query I suggest you use the Graph API Explorer before adding the query to your application code. It's a quick way to see if the error is in your query or elsewhere. For example, if you want to find everyone named John, use this link http://developers.facebook.com/tools/explorer?method=GET&path=search%3Fq%3DJohn%26type%3Duser. Just make sure to click Get access token on the right if you're using the Explorer for the first time, otherwise the query will return an error.
Related
I'm designing a REST API where, amongst others, there are two objects.
Journey
Report
For each Journey there are many Reports enroute, and each Report has exactly one associated Journey.
A user might create a Journey using the API as follows...
POST /journey/
Then retrieve the details...
GET /journey/1226/
The first question is, if a user wanted to post an Report to their Journey, which is the 'correct' URL structure that the API should impose? This seems intuitive to me...
POST /journey/1226/report/
...or is this the case...
POST /report/
...whereby in the latter, the Journey ID is passed in the request body somewhere?
The second question is, how might one go about implementing the first case in a tool such as the Django REST framework?
Thanks!
The URL/URI structure is almost completely irrelevant. It is nice to be able to read it, or easily change or even guess it, but that is it. There is no "requirement" official or unwritten how they should look like.
The point is however, that you supply the URIs to your clients in your responses. Each GET will get you a representation that contains links to the next "states" that your client can reach. This means the server has full control over URI structure, the client usually has to only know the "start" or "homepage" URI, and that's it.
Here is an article which discusses this question, has some good points: http://www.ben-morris.com/hackable-uris-may-look-nice-but-they-dont-have-much-to-do-with-rest-and-hateoas/
Pass for the second question :) I didn't use that particular framework.
I am trying to figure out the right parameters for ItemSearch such that the API call will return the same result as on the website. Currently I am using these params it is not consistent with the website.
url_params = dict(
Service='AWSECommerceService',
Operation='ItemSearch',
AssociateTag=AMAZON_ASSOCIATETAG,
SearchIndex='All',
AWSAccessKeyId=AWS_ACCESS_KEY_ID,
Keywords=keywords,
ResponseGroup='Small,OfferSummary,Images'
)
For example if 'iphone%205s' is put in keywords, the API returns a list of iPhone protectors, while searching on the website gives iPhones as top results.
I am also trying to figure out why this is for book searches. One possible answer I found online was that the websites search feature might use more elaborate queries than just one simple API call. For example, it may take into account other factors into the search (not sure what that might be but it may).
I want to validate an opinion with you.
I have to design a web service that searches into a database of restaurants affiliated to a discount program in a specific country around a given address.
The REST call to such a webservice will look like http://server/search?country=<countryCode>&language=<languageCode>&address=<address>&zipcode=<zipcode>
The problem is that some countries do not have zipcodes or do not have them in the entire country.
Now, what would you do if the user passes such a parameter for a country that does not have zipcodes, but he/she passes a valid address?
Return 400 Bad request.
Simply igonre the zipcode parameter and return results based on the valid address
Return an error message in a specific format (e.g. JSON) stating that zipcodes are not supported for that country
Some colleagues are also favoring the following option
4. Simply return no results. And state in the documentation that the zipcode parameter is not supported. Also we have to create a webservice method which returns what fields should be displayed in the user interface.
What option do you think is best and why?
Thanks!
Well the OpenStreetMap Nomination Server returns results even if you dont know the ZIP Code and you can look at the results anyway. What if the user doesnt know the zip code but wants to find hist object?
I would try to search for that specific object anyway, especially because you said that some countries have zip codes partially.
If you simply return nothing te user doesnt know what went wrong and he wont know what to do.
That would depend on the use case. How easy is it for a user of the API to trigger that case? Is it a severe error which the user really should know how to avoid? Or is it something that is not entirely clear, where a user may know (or think he knows) a zipcode where officially there shouldn't be one? Does it come down to trial and error for the user how to retrieve correct results from your API? Is it a bad enough error that the user needs to be informed about it and that he needs to handle this on his side?
If you place this restriction in your API, consider that it will have to be clearly documented when this case is triggered, every user of the API will have to read and understand that documentation, it needs to be clear how to avoid the problem, it needs to be possible for the user to avoid the problem and every user will have to correctly implement extra code on his side to avoid this problem. Is it possible for the user to easily know which areas have zipcodes and which don't?
I think the mantra of "be flexible in what you accept, strict in what you output" applies...
This statment is found in the graph api (https://developers.facebook.com/docs/reference/api/)
Objects with location. The following will return information about
objects that have location information attached. In addition, the
returned objects will be those in which you or your friend have been
tagged, or those objects that were created by you or your friends.
But it is not stated how to make this call, has anyone figured it out?
In order to get pure checkins the following is used: https://graph.facebook.com/search?type=checkin
But it is not stated how to make this call, has anyone figured it out?
Like any other Graph API call …? With a simple HTTP request, probably including an access token, or with the help of one of the SDKs, which take care of the more basic aspects of this for you.
If you do a search for location objects you need to include the point and radius for your search, see example below for a search over the center of Gothenburg with 1000 meter distance (max for distance is 50000 meters)
https://graph.facebook.com/search?type=location¢er=57.708549,11.975098&distance=1000&access_token=xxx
I have coordinates as latitude and longitude, I want to get a list of place from facebook using facebook query (FQL). Does anyone have an example of how to to that? I am also fine with using the graph api
It's easy with the Graph API:
https://graph.facebook.com/search?q=coffee&type=place¢er=37.76,-122.427&distance=10000&access_token=AAAAAAITEghMBAB7yPm6SoZAeJyU7MnYXqllWwcTLQDZB2g96QCmpb2B2QDAWtPfCkRJtCN8tnPbDrTqaZA6M9fmHdm1FXB0kbmaXEShDwZDZD
(Via the online documentation)
I can't get it to work with FQL, although the correct syntax appears to be:
SELECT name,description,geometry,latitude,longitude,checkin_count,display_subtext FROM place WHERE latitude=40.797702 AND longitude=-105.587082
(Try it)