I'm getting started developing a facebook game and I'm hitting some problems in my understanding straight away. I'm hoping there's someone wise out there who can set me straight.
Like most games I want to be able to invite people to join, and then to know when they HAVE joined.
I am using Graph Api version 2.2 - as I understand that version 1.0 will be switched off come April 2015. The issue I am getting to here is that the IDs / tags are 'temporary' so there will be a problem matching them up.
Using this I can request a list of friends that already have the app installed. (great). And I (should) receive back a list of IDs for these players. I can then send them an AppRequest which will prompt them to load up the game. (good so far).
At this point lets assume that one of more friends all load up the game. Also assume that I have some back end processing on my server so each of these friends can say to the server "I have the game loaded, and I know 'my' ID these friend IDs".
In the game I'd then like to show a list of my current friends that actually have the game running - right now. This will be possible because the server know's everyone's ID, and my ID, so it can say "here are the friends that you know..."
I hope you are still following me.
So can the Graph API 2.2 request both
(a) My own ID (??)
(b) My friend's IDs.
- which are matchable and expire at the same period of time. (yes, I know this one is possible)
Is (a) possible? An even if it is, is it an ID that is matchable to temporary friend IDs or is it of another type that can be used for different purposes. (for instance I read that the taggableFriend IDs cannot be used for appRequests).
If it is not possible can anyone explain to me the correct approach?
It seems to me that in the remaining days of Graph API 1.0 you don't have these problems as
(a) You can get your own ID using the FQL interface,
and (b) IDs are permanent so you can store them away in a database to save on these matching problems.
For instance, in Api 1.0 each running instance of the app would be able to get away with only requesting it's own facebook owner's ID. (no friends). - so long as friends had been asked at some point in the past. Your own server would have enough info to be able to match them up and say "I knkow these IDs are your friends still".
But how do I do it in Graph API 2.0 ?
I won't have my game finished before April 2015 so there is really no point in using the older API.
There is probably a lot of stuff in here you already know but I think it would be best if I start from scratch just to get thoughts aligned.
User ID
There are currently two types of IDs for users available
Global ID
App scoped ID
Most if not all applications moving forward should be using the app scoped ID.
User Friends
As long as you request user_friends permission you will get a list of friends also using the application.
Invitable Friends API
As long as your app is a game on canvas you will be returned a full list of user's friends that you can invite via invite Tokens. These tokens are temporary and can be used in the Request Dialog.
Now to your scenario, your game is running and the /me/friends list returns
{
"data": [
],
"summary": {
"total_count": 5000
}
}
So, no friends are currently in the game. You invite friends using invite tokens from /me/invitable_friends and one of your friends join.
Recall `/me/friends`
{
"data": [
{
"name": "phwd friend lastname",
"id": "app-scoped-id-1"
}
],
"paging": {
"next": "https://graph.facebook.com/v2.2/me/friends..."
},
"summary": {
"total_count": 5000
}
}
So app-scoped-id-1 (which will be a numeric) is the app scoped ID of your friend. This should not change.
So the ids that you will store are
/me?fields=id the current player
/me/friends?fields=id the player's friends who are also playing
Related
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.
I was wondering if there is any way to get user checkin information for different places based on the place_id. Facebook documentation keeps changing around and I'm not sure if this is possible now? Seems like it was possible in older API versions.
Any help will be greatly appreciated.Thanks
Checkins are deprecated since Graph API v2.0. You can get the total count (field were_here_count) of checkins to a place with a call like
GET /BrandenburgerTorBerlin?fields=id,name,were_here_count
which gives the result
{
"id": "145183205532558",
"name": "Brandenburger Tor",
"were_here_count": 128511
}
Hi all,
I'm new to REST and Web API. I'm a bit confused on how to design URIs for my resources.
Given that I have a domain with the following resources: Blogs, Posts and Users.
Blog (1) ------ (0..*) Post (0..*) ------ (1) User
A blog can have many posts and each post is associated with one blog. An user can have many posts and each post is associated with one user.
For Blog and User resources the URIs would be like the following:
GET /blogs - get list of all blogs
GET /blogs/{id} - get blog by id
POST /blogs - create new blog
PUT /blogs/{id} - update blog
DELETE /blogs/{id} - delete blog
GET /users- get list of all users
GET /users/{id} - get user by id
POST /users - create new user
PUT /users/{id} - update user
DELETE /users/{id} - delete user
But what about Posts resource? How to handle associations? I'm thinking of the following alternatives - which ones are correct and why?
-- Get all posts by blog
1. GET /blogs/{id}/posts
or
2. GET /posts?blogid={id}
-- Create new post in a blog
3. POST /blogs/{id}/posts
or
4. POST /posts (here I would then in the payload send the IDs of the resources this post is associated with. BlogId and UserId)
-- Get all posts by blog and by user
5. GET /blogs/{id}/posts?userid={id}
or
6. GET /posts?blogid={id}&userid={id}
If anyone could point me in the right direction here, I'd be grateful.
Since a post is always associated with a blog and a user ID, I would choose options 1, 3 and 5:
GET /blogs/{id}/posts
POST /blogs/{id}/posts
GET /blogs/{id}/posts?userid={id}
The first question you should ask yourself is how important it is to you that your API is truly RESTful? It's actually a lot more fiddly than it seems to achieve this.
Is your API going to be consumed only by your own software\organisation?
Will your API be accompanied by documentation?
If the answer to 1 or 2 above is true, then the value of being truly RESTful is questionable... it's all or nothing with REST so either you go the whole hog or you don't worry.
For an API to be a true REST API, it must be discoverable from a single entry point (see here: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven). Each call should return information on other related calls that can be made on that resource.. usually via links of some kind, this is one possible structure:
{
"Id" : 1,
"Identifier" : "123's First Blog",
"links" : [
{
"rel": "http://myapi/res/posts",
"href": "http://myapi/blog/1/posts"
},
{
"rel": "http://myapi/res/users",
"href": "http://myapi/user/123"
}
]
}
The rel is a link to a summary\definition of the resource, and the href should point to the api itself.
Anyways, the point of all this is that if you do want to be truly RESTful, then let the links between resources and uris dictate the design. Think about how you would discover the particulars for each call from a single starting point, and the structure should reveal itself much like software design through TDD.
If you don't need to be RESTful, then things become much simpler. Just design your API in the most natural way for you, your architecture, and your developers. If you document things properly, then this will lead to a much more efficient API and one that is quicker to develop against.
Mario's answer to this question is sound, and I would also favour those options over the others. I just thought you should know the whole story that accompanies such a desicion.
If this doesn't make sense or you would like more information then post a comment and I'll try to help :)
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.
Starting last month, it appears that community pages either require a user access token to access the graph image, or will not allow application to access the image.
As an example: The community page for Harold and Maude (105636526135846), last month would return a picture -- now calls to the graph do not include the picture string.
{
"id": "105636526135846",
"name": "Harold and Maude",
"link": "http://www.facebook.com/pages/Harold-and-Maude/105636526135846",
"likes": 143886,
"category": "Movie",
"is_community_page": true,
...
At one point it appeared that using an access token would work, however, now requesting '/105636526135846/picture' returns no picture and Facebook's embedded image is
http://external.ak.fbcdn.net/safe_image.php?d=AQBKNDbD3RCI0MXv&w=180&h=540&url=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fen%2Fc%2Fc4%2FHarold_and_maude.jpg&fallback=hub_movie
Alternatively FQL appears to return the proper information
>[
>> {
>>> "pic": "http://external.ak.fbcdn.net/safe_image.php?d=AQA4PX9DD7wlHZmC&w=100&h=300&url=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fen%2Fc%2Fc4%2FHarold_and_maude.jpg&fallback=hub_movie",<br />
>>> "pic_large": "http://external.ak.fbcdn.net/safe_image.php?d=AQBKNDbD3RCI0MXv&w=180&h=540&url=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fen%2Fc%2Fc4%2FHarold_and_maude.jpg&fallback=hub_movie"<br />
>> }<br />
>]
Is there something I'm missing with the graph? I'm concerned that the FQL method may stop working.
Wikipedia have started blocking certain images, based on their licensing. So Facebook runs it through a filter (safe_image.php) to check if it is allowed or not. If not, you get a default image. So using FQL will 'sometimes' return you a usable image, but the graph no longer will.
I have no idea if Facebook plan to continue offering the FQL call. Sorry!