"new" restfb vs. "old" Facebook API - facebook

For a new J2EE Facebook Connect project, do you recommend:
restfb (http://www.restfb.com), or:
Facebook Java API
(http://code.google.com/p/facebook-java-api)
The requirements cover pretty much everything supported by Facebook Connect.
Completeness, ease of use, stability, etc are important. But what matters the most to us are the odds that the selected library flourishes and ends up being the winner, if there is such at thing.
Thank you.

With the new OAuth2 based authorization flow and the Graph API, the amount of "work" an SDK does has been greatly reduced. I'd suggest that you choose a library that does not try to provide very high level abstractions, and instead understand and leverage the fact that you're making HTTP API calls (for instance, for parallelization of HTTP requests). We recently released an Android SDK which while not related to your question, may be a good point of reference.

For full disclosure, I mavenized RestFB and have commit rights to the project. That said, I was in the same position some time ago, needing some Java library for working with FB's Graph API. Originally, I tried out facebook-java-api, but it didn't support all the newer APIs. I peaked into the code at the time and saw some inherent inflexibility that made it overly complicated to do what I needed so I looked around for alternatives. In all fairness to facebook-java-api, perhaps I just caught them at a bad time (around 6 months ago, there were only minor updates to 2.x and no 3.x in sight at the time. I see they've released 3.0.2 recently).
Anyhow, I then found RestFB. What I liked about it from the very beginning was how clean and extensible the code was and that it didn't require any extra dependencies. The basic Graph API objects are built-in and it's very simple to create new ones. There were one or two minor things that didn't work out of the box, so I opened issues and Mark Allen, the founder of the RestFB project, seemed pretty responsive with fixing them so I stuck to using it. More recently, I contributed Maven build to the project since I was keen on seeing the RestFB libs on Maven Central to make it easier for myself to use them.

Related

REST API versioning and sdk

How do services like github,twilio,algolia,stormpath maintain rest api's along with SDK's for different languages? Do they generate such code using tools like enunciate or are they maintaining the client code themselves? I guess for github ,they are open sourced client libraries. My questions are:
How to sync between rest api changes and corresponding SDK changes.
What are the best practices for versioning of rest apis,as well as their sdk's ?What are the common pitfalls one must be aware of?
At Algolia we’ve developed a dozen of API clients on top of our REST API. Honestly, I must say we suffered a lot to create all of them /o\ I hope the following bullet points will help:
Why did we create our own API clients instead of just using libraries/tools to generate them (which is pretty common for REST API clients)?
be able to reach a 99.99% SLA, we decided to implement a “retry-strategy” in our API clients -> the Algolia index is always replicated on 3 machines -> if one goes down the API client will retry on the other ones -> this cannot be handled by generic libraries
to reach optimal performances, we wanted to be sure we control the way the HTTP keep alive works -> most of generic libraries doesn’t handle that as well
we wanted to force HTTPS as soon as possible
How did we proceed?
at the beginning, we were not super fluent in all those languages; so we started to look at other API clients implemented in each language to understand best practices
we got the help from 1 guy for Node.js and 1 for python
but it was really not OK until we decided to move all of them to Travis.CI + plug code coverage to reach 80-95% code coverage + automated tests -> obviously, we spot a lot of bugs :)
as soon as we release a new feature, we need to update all our API clients -> pretty painful…
to ease the README generation, we’ve developed a small tool generating the README for all languages. It’s super Algolia-specific but you can have a look at https://github.com/algolia/algoliasearch-client-readme-generator -> pretty painful to bootstrap as well :)
Things we learned:
maintaining all of them ourself make them act exactly the same, whatever the language -> super appreciable from a customer POV
if your community is building API clients, that’s cool; but they may not go so deep in the tests -> we’re testing ALL features in ALL API clients -> quality
we would do the same again if we needed to

Facebook API changes massive?

I don't quite know if my question fits here, but I don't know who else to ask...
I recently upgraded my socialengine plugin, which should allow me login to my site via Facebook. The reason I had to upgrade it because it didn't work anymore since Facebook changed the API (API-KEY --> APP-ID). I think this was around 2010!?
Now I bought the latest version of the plugin, just to find out that it still requires an API-KEY. Their support told me that it's not supported anymore because the version of my CMS is not supported anymore (nice to find that out after paying for it). However they offered me to make the plugin work for me, if I am willing to pay, with a hint that due to the massive changes in the API it will need a lot of work.
To come to my question: Have there really been such massive changes? Has a task like logging into a site via Facebook become that different? I am coming from a programming background, may i be able to fix this myself?
The Facebook API is constantly evolving with breaking changes all the time. 2010 is a long time ago for the FB API, so it sounds likely it'll be a lot of work updating the plugin (if the required API features are even still available!)

node.js JSON/REST framework for a single-page application

I'm developing an application that consists of a 'fat' javascript client backed by a JSON/REST server for data access. The data is stored in mongodb but the system should be flexible enough to switch to a relational backend if required.
I started out with pintura as the server side framework but recently ran into some problems (specifically with the perstore/filestore). I noticed that one problem has even been reported (including a fix) over a month ago, but there has been no reply to it and the issue is still present.
There seems to be relatively low activity in this project so I was wondering if many people are actually using it, and how stable the framework is.
Does anybody here have experience with this framework or know of an alternative framework that has similar capabilities?
I agree the project and the website/blog does not seem to be active, although the perstore repository does have recent activity. I'd contact the author there since your problem seems more related to that.
A search for REST on http://search.npmjs.org/ will show quite a few results, although I cannot recommend any from experience.

GAPI Class, Google Analytics API

I am about to start a new project in the Google Analytics API & PHP.
I read that Google Analytics will be deprecating XML v2.3 and v2.4 and in 6 months time, so aparently you will only be able to use v3 and retrieve information in JSON format.
http://analytics.blogspot.com/2011/12/introducing-google-analytics-core.html
My question is the following: Does this means that GAPI class won't work any longer? Anyone who has used this class before can help me answering this question ??
http://code.google.com/p/google-api-php-client/
In that case, any alternative suggestions of PHP classes that do the same thing.
Thanks so much
I've been using GAPI for a while now. And I can say with some confidence that yes it will break, if not due to XML it will be due to some other change google makes.
Having said that GAPI is the best solution I have found out there for php. It does break every 6 months to a year, usually needs one or two lines changing to fix. But GAPI is pretty popular so at least you know when your clients are calling saying analytics is throwing errors at them, you wont be the only dev tearing your hair out.
9 times out of 10, by the time I've got a problem someone else has found the fix - which is nice.
There are a few other php options out there but GAPI seems to be the most popular (usually the best way to go imho)
My approach is to build an analytics summary in the dashboard and provide a link to google analytics underneath so clients can see the full data or go there when GAPI breaks. I have been putting all my sites on the same modular system for a while now. I keep GAPI as a library in my admin layout module, this means I can make the fix once and roll it out to all my sites without too much drama.
In summary, use it but expect it to break - that way you wont be disappointed when it does.

Anyone know what tumblr is written in

Does anyone know what tumblr is written in? I have been trying to figure it out.
It's PHP...
http://www.marco.org/55384019
spiteshow:
I wonder if the Tumblr guys are using a framework or if it is all home brew.
Both: it’s a homebrew framework to add MVC structure and a useful secondary function library to PHP 5 that we started in 2006 and have constantly evolved into a very finely tuned framework for our needs. The same framework runs some of Davidville’s former consulting-client sites as well as all of my personal sites and projects. It’s not available publicly anywhere, but we may release it in the future.
The lead developer's blog features a lot of PHP-related material, and Tumblr was advertising for PHP developers a while ago. This isn't strong evidence, but it's possibly indicative and it's the best I could find.
Here's the full stack as of 2013.
"We're a LAMP based stack (Linux Apache MySQL PHP) with Scala for our many services. Other pieces of tech we use currently in production are Memcached, Varnish and Redis."
http://smcdermott.tumblr.com/post/46847264498/what-language-is-tumblr-written-in-all-php
I just logged in to my account and added the index.php and it worked, so it must be php.
http://www.tumblr.com/dashboard/index.php