reales - ¿Qué debe saber un desarrollador antes de crear una API para un sitio web basado en la comunidad?

introducción a android studio incluye proyectos reales y el código fuente pdf

Question

¿Qué cosas debería saber un desarrollador que diseña e implementa una API para un sitio web basado en la comunidad antes de comenzar la codificación pesada? Hay muchas API como Twitter API , Facebook API , Flickr API , etc. que son buenos ejemplos. ¿Pero cómo construirías tu propia API ?

¿Qué tecnologías usarías? Creo que es una buena idea usar la interfaz similar a REST para que la API sea accesible desde diferentes plataformas / clientes / navegadores / herramientas de línea de comando (como curl ). ¿Estoy en lo cierto? Sé que deben cumplirse todos los principios del desarrollo web como el almacenamiento en caché, la disponibilidad, la escalabilidad, la seguridad, la protección contra posibles ataques de DOS, la validación, etc. Y en lo que respecta a las API, algunas de las cosas más importantes son la compatibilidad y la documentación. ¿Me estoy perdiendo de algo?

Por otro lado, pensando desde el punto de vista del usuario (me refiero al desarrollador que va a usar su API), ¿qué buscaría en una API? Buena documentación? Muchas muestras de código?

Esta pregunta fue inspirada por la pregunta de Joel Coehoorn "¿Qué debe saber un desarrollador antes de construir un sitio web público?" .

Esta pregunta es una wiki comunitaria , así que espero que me ayuden a poner en un solo lugar todas las cosas que deberían abordarse al construir una API para un sitio web basado en la comunidad.

Answer 1

Si realmente quiere definir una API REST, haga lo siguiente:

1. olvide todos los problemas de tecnología que no sean HTTP y tipos de medios .

2. Identifique los principales casos de uso en los que un cliente interactuará con la API

3. Escriba un código de cliente que realice esos "casos de uso" contra un hipotético servidor HTTP. La única información con la que el cliente debe comenzar es la respuesta de una solicitud GET a la URL de la raíz del API . El cliente debe identificar el tipo de medio de la respuesta del encabezado de tipo de contenido HTTP y debe analizar la respuesta. Esa respuesta debe contener enlaces a otros recursos que permitan al cliente realizar todas las operaciones requeridas por las API.

   Al crear una API REST es más fácil pensar en ella como una "interfaz de usuario" para una máquina en lugar de exponer un modelo de objeto o modelo de proceso. Imagine la máquina que navega por la API de forma programática recuperando una respuesta, siguiendo un enlace, procesando la respuesta y siguiendo el siguiente enlace. El cliente nunca debe construir una URL en función de su conocimiento de cómo el servidor organiza los recursos .

4. Cómo se formatean e identifican esos enlaces es fundamental. La decisión más importante que tomará al definir una API REST es su elección de tipos de medios . O bien necesita encontrar formas estándar de representar esa información de enlace (piense en Atom , microformats , relaciones de enlace atómicas , relaciones de enlace HTML5 ) o si tiene necesidades especializadas y no necesita un gran alcance para muchos clientes, entonces podría crear sus propios media-types .

5. Documente cómo están estructurados esos tipos de medios y qué enlaces / relaciones de enlaces pueden contener. La información específica sobre los tipos de medios es fundamental para el cliente. Hacer que un servidor devuelva Content-Type: application / xml es inútil para un cliente si quiere hacer algo más que analizar la respuesta. El cliente no puede saber qué está contenido en una respuesta de tipo application / xml. Algunas personas creen que puede usar el esquema XML para definir esto, pero esto tiene varias desventajas y viola la restricción REST del "mensaje autodescriptivo".

6. Recuerde que el aspecto de la URL no tiene ninguna relación con el funcionamiento del cliente. La única excepción a esto es que un tipo de medio puede especificar el uso de URI con plantilla y puede definir parámetros de esas plantillas. La estructura de la URL será importante a la hora de elegir un marco del lado del servidor . El servidor controla la estructura de la URL, al cliente no le debe importar. Sin embargo, no permita que el marco del lado del servidor dicte cómo el cliente interactúa con la API y sea muy cauteloso al elegir un marco que requiera que cambie su API. HTTP debe ser la única restricción con respecto a la interacción cliente / servidor .