Thrift as a Public API replacement for REST?

Question

I started creating a API for a new site I'm working on.

I originally wanted to make it an normal REST API but I keep thinking about how cool thrift would be with the ability to compile multiple client libraries in one batch.

Is Thrift a viable option for a public API ,sockets and all, or should I stick with REST?

And if REST what would the best approach for creating multiple client libraries or would I just have to get down and dirty and actually write them?

Else if Thrift, would I compile the libraries and just offer download links or simple give the developers the .thrift file to generate their own library ?

Note: It's still a small site so I would create the Thrift Specification file just for the API.

Answer 1

First, REST and Thrift are apples to oranges -- former is a general style, latter specific binary RPC system.

But for public interfaces I think that REST using standard textual formats (JSON or XML, usually) makes more sense; as it is easier to access from any language or platform; and although there are Thrift clients on many platform it is still more work. It also forces specific access style on clients, pretty much having to use specific Thrift client library.

So question would rather be what exactly are you trying to gain? What exactly do you consider "cool" there? If you just want to play with new technology, there's nothing wrong with that but you should first play with it, then see if it makes sense.

Answer 2

If your API is simple enough that you can express it with REST and with acceptable performance, than it would probably better to stick REST, since there is usually lower barrier to write client code for REST based API.

If on the other hand REST has complexity or performance issues, go with thrift or something else more suitable.