22

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.

Improve this question
4
  • It depends: who will connect and how? (Personally, I've found ProtocolBuffers to be nicer and better designed, even if there is no "standard" RPC server. For more sophisticated RPC there are things like ICE but, again, who will connect and how?)
    – user166390
    Commented Apr 6, 2012 at 0:52
  • So in Google Buffers I would be able to still define the object types, serialize and send over http. Much like a replacement to JSON but with a defined Type that a Client is Expecting? Have any experience with this in PHP ?
    – Johann du Toit
    Commented Apr 6, 2012 at 0:55
  • 2
    Protocol Buffers is a binary serialization protocol, much like Thrift is. (Thrift is just an "all-in-one" package since it also includes the service end-point implementations.) There is support for RPC end-points in ProtocolBuffers, as RPC support was designed in, but there is no "standard" server implementation. There is, however, projects that provide the appropriate RPC end-points.
    – user166390
    Commented Apr 6, 2012 at 2:26
  • If you decide to go with REST-like APIs: and want stub generation, check out swagger, and if you want generic client check out HAL and Hypermedia APIs in general.
    – mb21
    Commented Sep 24, 2014 at 12:21

4 Answers 4

Reset to default
12

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.

Improve this answer
3
  • Just looking at different ways of doing things. Was building the Rest API and the Java Library and started wondering can't this be done for me? But I agree REST would be the most usable by any of the clients accessing the API. But this all this work per library seems like trouble. What if I add another parameter to a object in the output of the API, I then have to update all the client libraries for the value and mistakes are bound to happen. Any advice ?
    – Johann du Toit
    Commented Apr 12, 2012 at 9:17
  • 2
    Same is true with Trhift, n'est pas? You must modify schema, everyone must recompile this to new classes... With Java though, REST, I use POJOs, which can be shared. Data binding packages (Jackson for JSON, JAXB for XML) can deal with serialization/deserialization nicely. And then basic HTTP client (Apache or async-http-client); or better yet, Jersey-client, can make access simple.
    – StaxMan
    Commented Apr 12, 2012 at 18:41
  • Makes sense thanks. Ended up writing a normal rest api and making custom libraries.
    – Johann du Toit
    Commented Apr 13, 2012 at 13:49
10

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.

Improve this answer
0

You will be in the same boat if developing different libraries yourself. I think REST would be easier for people to use even without the library (or if they implement their own). On the other hand if what you like about Thrift is that it is binary, json can be used in similar way too, check here for more info http://bsonspec.org/

Improve this answer
0

One of the big advantage of REST is that you don't have to create the client libraries. You can just point devs to your list of endpoints and they should be able to figure it out from there. Some big badly designed REST services will provide client libraries to mask their ugliness, but if the API is simple and well designed it shouldn't be necessary.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.