¿Cómo funcionan las API web? [cerrado]

He oído hablar de muchas API web como la de Facebook, Twitter, etc., que ayudan a terceros a acceder a los datos y manipularlos. Me gustaría saber cómo funciona una API web. ¿Cuáles son los conceptos básicos de una API web?

Si quiero crear una API para mi sitio, para que las personas puedan acceder o actualizarla, ¿con qué tendré que empezar?

En su forma más simple, crea un conjunto de solicitudes GET / POST a las que cualquiera puede llamar y publicar la información en las URL, parámetros y efectos. OBTENGA solicitudes para tareas de solo lectura y solicitudes POST para cualquier cosa que cambie los datos en el servidor.

Agregue un sistema de autenticación si es necesario y tendrá una API web simple.

Una API web es solo una interfaz para permitir el acceso a su sistema (como el sitio) a través de métodos de solicitud HTTP estándar . Los datos en sí mismos generalmente se envuelven en algún formato estándar (como JSON o XML ) para facilitar su manejo.

Aquí hay un ejemplo de API web para 'TextWise'

Actualmente estoy desarrollando una API para la plataforma de virtualización de mi empresa ahora. Puede abordarlos de diferentes maneras, pero mi favorito (y la ruta más rápida para hacer que algo funcione que la gente pueda entender) es usar solicitudes HTTP GET simples y devolver una respuesta JSON.

Mi URL se ve así:

domain.com/method/call/subcall?key=key&data=something

Luego desgloso las variables HTTP GET y hago lo que la persona que llama quiere hacer con ellas. Una de las principales razones por las que me inscribí como usuario beta para el desarrollo de la API de Stack Exchange fue que sabía que sería una experiencia de aprendizaje tremenda, y de hecho lo fue .

Por lo general, devuelvo dos matrices codificadas JSON, una de ellas result, que básicamente solo dice si la llamada fue exitosa y da un código de error / cadena de error si no. Por lo general, solo se llama al otro data, y el contenido se describe en la documentación de esa llamada en particular. Además, las API basadas en GET son mucho más fáciles de probar y depurar.

Existen muchos otros formatos, como SOAP / XMLRPC, solo encuentro que elegir JSON me brinda una increíble simplicidad y libertad de elección.

Por ejemplo, si necesito enviar muchos campos y no quiero tratar con un montón de variables GET, puedo hacer esto (ejemplo en PHP)

$to_send = base64_encode(json_encode($some_array));

Eso se decodifica fácilmente en el otro lado, dándome docenas de variables con las que trabajar, a la vez que solo acepta 2 - 3 variables GET a través de la API.

Solo trato de mantener mis métodos y llamadas breves y concisos, y diseñarlos de tal manera que cada llamada devuelva una respuesta uniforme 'funcionó o falló', seguida de los datos solicitados.

Esa es en realidad una pregunta muy amplia. En el sentido más básico, una API web funciona cuando un cliente (como un navegador web) realiza una solicitud HTTP de algún tipo a un servidor web. El servidor examina esa solicitud para averiguar qué quiere el usuario y luego devuelve los datos en algún formato (como una página) que el cliente luego examina para obtener lo que quiere. Estas son casi las únicas cosas que las API web tienen en común; Me doy cuenta de que esto realmente no responde a su pregunta, pero quería dar una razón por la cual la pregunta es tan amplia.

Hay todo tipo de formas en que un cliente podría formatear su solicitud, o que un servidor podría formatear su respuesta, por lo que para que algo tenga sentido, el cliente y el servidor deben acordar algunas reglas básicas. En términos generales, hoy en día hay dos estilos muy generales que se utilizan para este tipo de cosas.

Llamada a procedimiento remoto (RPC)

En una API de estilo RPC, generalmente solo hay una URL para toda la API. Lo llama PUBLICANDO un documento de algún tipo que contiene información sobre lo que desea hacer, y el servidor devuelve el documento que tiene lo que desea. En términos generales de computación, el documento de solicitud generalmente tiene un nombre de función y algunos argumentos.

Algunos estándares para este estilo de API incluyen XML-RPC y SOAP. Estos estándares intentan crear un formato que pueda usarse para describir las llamadas a funciones que está realizando, o incluso para describir toda la API.

Transferencia de estado representativa (REST)

En una API de estilo REST, no tiene tanto una URL para la API como un espacio de nombres : un servidor o una carpeta dentro de un servidor, donde residen muchos objetos diferentes, y cada URL dentro de este espacio de nombres se convierte en parte de la API. En lugar de decirle al servidor que desea utilizar la API, la URL indica al servidor que desea utilizar la API en . Luego, utiliza el método HTTP, y posiblemente el cuerpo de la solicitud, para explicar lo que desea hacer a ese objeto: GET (recuperar algo que ya está allí), POST (crear algo nuevo), PUT (reemplazar algo que ya está allí) o BORRAR (deshacerse de algo que ya está allí). Hay algunos otros verbos que puedes usar, pero estos son, con mucho, los más comunes.

Hasta ahora, no he mencionado formatos estándar para REST. En teoría, podría usar casi cualquier formato. HTTP ya permite decir lo que quiere hacer y para qué quiere hacerlo, por lo que el formato del cuerpo de la solicitud podría ser casi cualquier cosa: alguna representación del objeto que desea crear o reemplazar. Pero en la práctica, los autores REST tienden a acordar un formato de todos modos, porque sería difícil dar sentido a cada formato posible.