FQL Tables

You can use the following tables as a reference for constructing FQL queries.

• album
• application
• comment
• cookies
• connection
• daily_metrics -- This table has been deprecated. You can get application metrics from the metrics table instead.
• event
• event_member
• family
• friend
• friend_request
• friendlist
• friendlist_member
• group
• group_member
• link
• link_stat
• listing -- This table has been deprecated.
• mailbox_folder
• message
• metrics
• note
• notification
• page
• page_admin
• page_fan
• permissions
• photo
• photo_tag
• profile
• standard_friend_info
• standard_user_info
• status
• stream
• stream_filter
• thread
• translation
• user

For more information click this link where these texts are taken from.

Facebook multiquery

Evaluates a series of FQL (Facebook Query Language) queries in one call and returns the data at one time.

This method takes a JSON-encoded dictionary called queries where the individual queries use the exact same syntax as a query made with fql.query. However, this method allows for more complex queries to be made. You can fetch data from one query and use it in another query within the same call. The WHERE clause is optional in the latter query, since it references data that’s already been fetched. To reference the results of one query in another query within the same call, specify its name in the FROM clause, preceded by #.

For example, say you want to get some data about a user attending an event. Normally, you’d have to perform two queries in a row, waiting for the results of the first query before running the second query, since the second query depends on data from the first one. But with fql.multiquery, you can run them at the same time, and get all the results you need, giving you better performance than running a series of fql.query calls. First, you need to get the user ID and RSVP status of each attendee, so you’d formulate the first query – query1 – like this:

"query1":"SELECT uid, rsvp_status FROM event_member WHERE eid=12345678"

Then to get each attendee’s profile data (name, URL, and picture in this instance), you’d make a second query – query2 – which references the results from query1. You formulate query2 like this:

"query2":"SELECT name, url, pic FROM profile WHERE id IN (SELECT uid FROM #query1)"

This method also has better performance than running a series of fql.query calls with batch.run.

For more information about fql.multiquery see this link where these texts are taken from.

Facebook Query Language

Facebook Query Language, or FQL, allows you to use a SQL-style interface to more easily query the same Facebook social data that you can access through other Facebook API methods (assuming your application has access!). For mpr details look Facebook FQL.

Facebook RESTfull API

With the Facebook RESTfull API, you can add social context to your application by utilizing profile, friend, Page, group, photo, and event data. for more details look Facebook RESTfull API.

Multiple action links problem in Facebook

We're focused on creating the best ways to empower users to share with their friends, as well as providing developers with the tools they need to make applications social and add value to the Facebook experience. As a part of a greater effort to simplify the site, Facebook developers made it easier for users to discover the most interesting content by modifying the home page stream to include two views:

§ News Feed focus on popular content, determined by an algorithm based on interest in that story, including the number of times an item is liked or commented on.

§ Live Feed display all recent stories from a large number of a user's friends.

Stories your applications generate can show up in both views. The best way for your stories to appear in the News Feed filter is to create stories that are highly engaging, as high quality, interesting stories are most likely to garner likes and comments by the user's friends.

In addition to making the site cleaner and simpler for users, they are also making our APIs clearer and more straightforward for developers. They built many APIs to enable you to create rich social experiences for your users, and while they create these APIs to match pace with the evolution of the features offered, we often maintain similar, more primitive versions as well. This creates a sea of different methods with overlapping functionality. To make it simpler and easier to develop on Facebook, they are streamlining our APIs, beginning with those that publish older-style, template-based Feed stories.

Going forward, the only way to publish Feed stories into the stream is via the stream publishing methods (stream.publish, FB.Connect.streamPublish, and Facebook.streamPublish). Posts published using the stream publishing methods contain only structured plain text data, which makes them easier to render on a variety of devices, including mobile phones and gaming consoles. For everyone else, these changes took place on December 20th, 2009.

This means that they discontinued support for the following:

· Template bundles. You should start using stream attachments with the stream publishing methods instead.

· feed.publishUserAction

· feed.publishTemplatizedAction

· Facebook.showFeedDialog and FB.Connect.showFeedDialog

· Publisher stories that use templates (please transition them to use stream attachments).

· Feed forms that reference the feedStory form and the multiFeedStory form.

· One-line stream stories.

They still publish stories that call users.setStatus and status.set, but encourage all developers to migrate to the stream publishing methods, as they let you set a user's status easily.

They have already made a few changes to how stream stories are rendered. First, they are shrinking the size of images to be rendered at a maximum of 90 pixels high or 90 pixels wide. Also, stream stories only display the first image that has been passed to them. Most Facebook stories use a single image, and many use no images at all. If the stream story contains more than one image or a significant amount of text, the first image and a couple lines of text display initially, and the user have the option to click a "See More" link to display the rest of the story. They find that the best images in stream stories are directly relevant to the action taken with the application. For example, if the story announces a user's high score in a game, the image should show that exact score. If the story shows content the user has created (for example, photos taken or art created), the image should be that user-generated content. Highly repetitive images that show up over and over aren't nearly as interesting or engaging.

They have made changes to action links to create a cleaner user experience. Going forward, a stream story can have a maximum of one action link and 25 characters in the link. Facebook's own action links tend to be even shorter than that ("Comment", "Like", "Share", "Become a Fan" are all ten characters or fewer). They strip out "formatting" characters (for example, leading spaces, pipes, and brackets) to keep in the same simple aesthetic as the rest of Facebook.

They look forward to making our APIs more straightforward and hope you are too. They welcome your comments in their Developer Forum.

These texts are taken from the blog.