Announcement Announcement Module
No announcement yet.
Graph api and access number of likes for multiple pages Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Graph api and access number of likes for multiple pages

    Does the Spring social Facebook api provide something like accessing:

    What I basically want to do is in 1 request access multiple profiles/pages to (at least) get the likes count.
    Probably I will be interested in more detailed info like name, location etc.

    I checked the PageOperations ( but this only contains a method to retrieve a single page (but with likes count and other additional info I would need).

    For reference here the result of the above ( Graph api call:
    "fcbarcelona": {
    "likes": 39131950,
    "id": "197394889304"
    "RealMadrid": {
    "likes": 34940859,
    "id": "19034719952"

  • #2
    Currently the Spring Social Facebook API does not support this kind of call. But I can see how it'd be useful. The challenge here is with the fields parameter. There are many things you can ask for there and if those things are returned, where would they be placed? Would I need to create a domain object capable of holding almost any field that could be asked for (most would be blank/null unless they're asked for)? Or should each object have a Map property to carry the extra stuff? Or should it be even more clever and allow you, the developer, to provide your own domain type to contain the extra fields?

    That last option is the one that sounds most appealing and I really should give it some more thought. Maybe it should work something like how the FqlOperations.query() method works with a result mapper to help populate the object.

    Note that although you may be asking for page data, the operation in your example is actually a search operation (and thus could pull back stuff unrelated to pages). Therefore, the solution should treat it as a search operation. And maybe the search operation is flexible enough to return results in any type the developer wants using a result mapper. Again, more thought is due to this.

    May I ask you to create an improvement issue at to track this?


    • #3
      I agree this will get complicated to suit everybody's needs.
      For my case I think it's best to use FQL instead.

      Thanks for the feedback,


      • #4
        I agree it would be difficult to come up with an implementation that would suit anybody.
        While looking into this, I think using the FQL support is better for me at the moment.

        Thanks for your feedback anyway,