¿Qué hace que una API sea ReSTful? ¿Qué alternativas hay para REST?

Una API es RESTful si toda la información necesaria para procesar la solicitud entrante está contenida dentro de esa solicitud. Técnicamente hablando, ese arreglo se llama ‘en banda’.

Una API no es RESTful si, al recibir la solicitud entrante, el código implementado que se supone que procesa esa solicitud necesita información extraña para procesar con éxito la solicitud. En la jerga técnica, ese arreglo se llama ‘fuera de banda’.

Esta distinción es similar al debate sobre si es mejor si el propósito de la conversación está preestablecido antes de que comience la conversación, o si es mejor si el propósito de la conversación es reconocible solo una vez que participamos en la conversación.

Es discutible qué enfoque (RESTful o no RESTful) es mejor, más deseable. Igual que es discutible si la unión temprana o la unión tardía son mejores cuando se trata de escribir software. Su experiencia puede ser diferente.

De acuerdo con la disertación ( https://www.ics.uci.edu/~fieldin …), algunas de las características de REST son:

  1. Arquitectura del servidor del cliente
  2. Ser apátrida
  3. Caché
  4. Una interfaz uniforme
  5. Una arquitectura en capas

Cuando hablamos de una interfaz uniforme que se refiere a la interacción con los recursos utilizando los verbos HTTP: GET, PUT, POST, PATCH, DELETE, etc. Estás realizando esas acciones en cosas, los recursos. Si está haciendo algo más, es RPC sobre HTTP, algo completamente diferente.

En cuanto a qué más hay, bueno, hay RPC como mencionamos anteriormente. También hay cosas como SOAP, XML RPC, CORBA, AMF … un montón de otras opciones.

En resumen, no existe un estándar oficial para los servicios RESTful. RESTful es más un patrón arquitectónico que un protocolo que generalmente utiliza HTTP para implementar API RESTful.

De las pautas de la NSA para implementar API RESTful,

Los principios básicos de REST son: simplificar sus operaciones, nombrar cada recurso (con un URI) y utilizar los comandos HTTP GET, PUT, POST, DELETE de acuerdo a cómo se describe su uso en el HTTP RFC original.

SOAP no puede considerarse como una alternativa directa a REST, ya que el primero es un protocolo y el segundo es un patrón. Sin embargo, puede considerar muchas otras alternativas, como las API de orquestación / experiencia, los protocolos binarios como los búferes de protocolo, Apache Thrift.