¿Thrift como un reemplazo de API pública para REST?

Question

Comencé a crear una API para un nuevo sitio en el que estoy trabajando.

Originalmente quería convertirla en una API REST normal, pero sigo pensando en lo genial que sería la economía con la capacidad de compilar varias bibliotecas de clientes en un solo lote.

¿Es Thrift una opción viable para una API pública, sockets y todo, o debo seguir con REST?

Y si fuera REST, ¿cuál sería el mejor enfoque para crear múltiples bibliotecas de clientes o simplemente tendría que escribirme?

Si no fuera por Thrift, ¿compilaría las bibliotecas y simplemente ofrecería enlaces de descarga o simplemente daría a los desarrolladores el archivo .thrift para generar su propia biblioteca?

Nota: todavía es un sitio pequeño, así que crearía el archivo de especificación de Thrift solo para la API.

Answer 1

Estarás en el mismo barco si desarrollas bibliotecas diferentes tú mismo. Creo que REST sería más fácil de usar para las personas incluso sin la biblioteca (o si implementan la suya propia). Por otro lado, si lo que te gusta de Thrift es que es binario, json también se puede usar de forma similar, consulta aquí para obtener más información http://bsonspec.org/

Answer 2

Primero, REST y Thrift son manzanas con naranjas; el primero es un estilo general, el último es un sistema RPC binario específico.

Pero para las interfaces públicas, creo que el REST con formatos de texto estándar (JSON o XML, por lo general) tiene más sentido; ya que es más fácil acceder desde cualquier idioma o plataforma; y aunque hay clientes Thrift en muchas plataformas, todavía hay más trabajo. También impone un estilo de acceso específico en los clientes, teniendo que usar una biblioteca de clientes específica de Thrift.

Así que la pregunta preferiría ser qué es exactamente lo que estás tratando de ganar ¿Qué consideras exactamente "cool" ahí? Si solo quieres jugar con la nueva tecnología, no hay nada de malo en eso, pero primero debes jugar con ella y luego ver si tiene sentido.

Answer 3

Si su API es lo suficientemente simple como para expresarlo con REST y con un rendimiento aceptable, entonces probablemente sería mejor pegar REST, ya que generalmente hay una barrera menor para escribir código de cliente para la API basada en REST.

Si, por otro lado, REST tiene problemas de complejidad o rendimiento, opte por el ahorro o algo más adecuado.

Answer 4

Una de las grandes ventajas de REST es que no tiene que crear las bibliotecas cliente. Simplemente puede apuntar a los desarrolladores a su lista de puntos finales y deberían poder resolverlo a partir de ahí. Algunos grandes servicios REST mal diseñados proporcionarán bibliotecas cliente para enmascarar su fealdad, pero si la API es simple y bien diseñada, no debería ser necesaria.