The Many Ways in Which the Yammer API Sucks

Posted on Sunday, the 1st of March, 2009.

Tagged: , , and

A lot of the guys out in our San José office have been using Yammer recently. For the uninitiated, Yammer is a lot like Twitter, but with access controls, making it more suitable for communication within a company.

Yammer exposes an API for developers to hook into, so I thought it would make for a fun Sunday afternoon project to see if I could put together an Opera Panel interface, which - if done right - might double as a mobile Web interface. Unfortunately the Yammer API is awful, so awful that it's basically futile to try to work with it. Here are some of the ways in which the Yammer API sucks.

Comments

Posted by Ciaran McNulty on Monday, the 2nd of March, 2009.

In a well-done REST service the "spec" should just be about what the various content types involved are - a formal spec of the available methods shouldn't be required because, well, it's here and in later RFCs:

http://tools.ietf.org/html/rfc2616

I think where HTTP services go wrong is that they try to get the client to build URLs based on a scheme that's informally defined in some document, which I think is antithetical to RESTfulness - URLs should really be opaque to the consuming app.

SOAP is very easy to use in comparison, from the developer point of view, but like all things it's a trade-off. SOAP includes a lot of transfer overhead but integrates well with an OOP style while REST is very efficient at the HTTP level.

For instance it has a very rich caching semantic that's widely implemented - the fact you can buy a bit of hardware, or install some standardised software to sit between your service and the web and provide caching is pretty useful.

On another subject, OAuth is a mess but is a good solution to "I want this application to be able to use this service, but I don't trust it enough to give it my login". For that one win you get a whole world of pain in trying to implement the bloody thing, but I've not seen a better solution to that problem.

Hopefully, like OpenID, it'll get bundled over time into libraries that take that pain away. It'd certainly be useful for services like Yammer to offer "direct" login as well as OAuth.

Posted by Simon Harris on Wednesday, the 4th of March, 2009.

Ciaran - unusually, we appear to agree on a lot of this. However, I'll take issue on this point:

"a formal spec of the available methods shouldn't be required because...[RFC 2616]"

I don't think that this gets REST off the hook. I love HTTP to bits (I owe my career to it) but the HTTP RFCs do not tell me anything useful about how to consume your REST service; if I want to work with your API, I still need to trawl through that informal Word/Wiki/Web document you mention, and then manually code each of the calls myself. And I'm fairly busy these days, y'know?

Admittedly, I don't know what you mean - in this context - when you say "what the various content types involved are", or how that would help. Can you explain a bit more?

Posted by Ciaran McNulty on Wednesday, the 4th of March, 2009.

Well, the available actions are GET, POST, PUT, DELETE and so forth, which are defined in HTTP. If you aren't allowed to do one of them then there's a response code that lets you know that, so there's not much more documentation needed.

For example, what I'd consider a "bad" REST service would be one that said something like "To find a user's details do a GET to /user/<userid>", because that's the sort of informally documented stuff you're worried about.

A better service might say that the /user resource represented a list of the users, so that the developer could request a representation of that. The documentation would then revolve around defining the types used in the data transfer, e.g. in this example maybe an XML format for listing the URLs of the user resources. You don't then need to say "you can GET these URLs" because, well, they're URLs.

I'm interested in your idea of some sort of formal service definitions for REST services, but don't quite know how that would work?

Posted by Cristian Vrabie on Monday, the 20th of December, 2010.

I cannot agree with your statements regarding OAuth. You basically say that we should throw security for coding simplicity which I think is deeply wrong. Yammer is corporate oriented so security is a priority. The credential auth you're suggesting is flawed and easy to crack -> OAuth. Is not even that difficult if you use (or build) a small framework.
I think you were in a lazy Monday morning when you wrote this :)

Posted by Simon Harris on Wednesday, the 15th of June, 2011.

No, Cristian, I did not say that. My gripe was with the sheer impossibility of building a working user interface on top of the Yammer API, let alone a mobile one.

Nearly two years on from my post, no one has managed it and Yammer is essentially dead. I hate to say I told them so but, well, I did.

Posted by Tommy Kelly on Thursday, the 6th of October, 2011.

> Yammer is essentially dead.

How so?

Posted by Simon Harris on Sunday, the 9th of October, 2011.

Tommy -

Dead in the sense that nobody uses it. Do you? Granted they still have a website, but there's no sign that they have a future.

Posted by Toby Beresford on Monday, the 23rd of July, 2012.

I've used Oauth2 with Yammer which is pretty easy.

Posted by Daisukeman on Thursday, the 13th of June, 2013.

I really liked your article (and it made be laugh, a lot!)..
But I do sense somewhere in between of your bad experience with the Yammer API you start to name all issues related with REST services.
So according to this, does Google, Facebook, Twitter, etc REST services using oAuth suck as well?
If not, how is this different?

Posted by Bob on Monday, the 24th of February, 2014.

I searched Google for Yammer API and yours was the second hit. Congratulations. So, five years later, opinion still the same? Yammer still around so I guess they didn't die. Have they improved? I'm comparing Jive, Yammer, "roll my own", etc. and curious what your thoughts are now.

Enter your comment: