"Hola, mundo"

Guía del codificador para escribir documentación de API

Peter Gruenbaum

¿Se ha visto alguna vez en una circunstancia donde su administrador le pide que escriba documentación para las API que desarrolló? Seamos honestos: si usted es como la mayoría de los desarrolladores, le encanta escribir código, pero detesta escribir cualquier otra cosa. Lo que es más, escribir le quita tiempo de las tareas cruciales que debe hacer, tales como desarrollo de características y solución de errores.

No es una sorpresa, entonces, que la documentación de API termine siendo frustrante y confusa para el lector, pues rara vez recibe la atención que necesita.

Este artículo es una guía acerca de como escribir documentación de API. Le describiré los componentes más importantes de documentación de API y proporcionaré algunas características acerca de como hacer que sea efectiva. También le daré algunas pistas para crear información general, código de muestra y material de referencia de buena calidad, lo que incluye datos acerca de dónde enfocar el tiempo y atención para obtener los mejores resultados.

¿Para qué hacer documentación acerca de sus API?

Comencemos con el aspecto no técnico del asunto. La documentación de API existe desde que se crearon los primeros lenguajes de programación. Se ha invertido una gran cantidad de tiempo en el desarrollo de procesos efectivos para la creación de documentación de calidad; aún así, la documentación de API bien escrita es bastante escasa. ¿Por qué es esto así?

Primero, muy pocas veces se da prioridad a la documentación. Aunque ésta tiene un gran impacto en la adopción de una plataforma de software, es difícil medir el impacto real de la documentación. Esto da como resultado que muy pocas veces se le proporcione suficiente tiempo y presupuesto a la documentación. Cuando se les pide a los desarrolladores escribir código, generalmente se les agrega esto a sus otras responsabilidades y ellos deben encontrar alguna manera de integrar esto a su agenda ya sobrecargada.

Segundo, desarrollar código y escribir documentación son dos habilidades diferentes. A veces, se les pide a los desarrolladores escribir en un idioma que no es su lengua materna. Pero, aunque ellos nazcan en una región angloparlante y se les solicite que escriban en inglés, es muy probable que no hayan mostrado una gran competencia en sus asignaturas de literatura y educación cívica en la escuela y que hayan preferido invertir ese tiempo solucionando problemas en sus clases de matemáticas y ciencias.

El primer paso de la creación de buena documentación de API es solicitar a la administración el tiempo y el presupuesto para hacerlo bien. Existen dos puntos principales que es necesario hacer saber a los administradores:

1. Una buena documentación puede aumentar la posibilidad de que se adopte la plataforma, pues implica una experiencia menos frustrante para los desarrolladores.
2. Una buena documentación reduce el costo de soporte técnico, pues permite a los desarrolladores hallar las respuestas a sus preguntas con más facilidad.

Argüir en favor de la importancia de buena documentación puede ser un desafío para usted si no le agrada escribir o si está completamente sobrecargado de trabajo, pero existe una alternativa. Si existe suficiente presupuesto, puede contratar a un escritor técnico para que reúna información para usted y escriba la documentación.

Como ocurre con los desarrolladores, encontrará escritores técnicos con una variedad de experiencia y conocimientos. Muchos escritores técnicos son más experimentados en la documentación y soporte técnico para usuario final. Sin embargo, para la documentación de API, necesitará encontrar a uno que efectivamente haya trabajado algún tiempo como desarrollador de software. En muchas compañías, ese tipo de escritores tienen un título como programador/escritor.

Los escritores técnicos que tienen en el bolsillo algo de experiencia en escribir código entienden el suplicio que es para los desarrolladores tratar de hacer que funcione una plataforma de software y también como buena documentación puede ayudar a mejorar el desarrollo de la plataforma. Además, ellos deben contar con bastante conocimiento especializado de lenguajes, algoritmos y patrones para leer su código y entender sus bibliotecas. Con este conocimiento y experiencia, la conversación técnica entre el escritor y el equipo de desarrollo será más efectiva y productiva.

No obstante, si el presupuesto le impide contratar a un escritor técnico, necesitará escribir la documentación usted mismo. Asegúrese de que la administración comprenda que usted necesitará tiempo para hacer esto, de la misma manera que sería necesario para crear una característica nueva.

Componentes de la documentación de API

La buena documentación de API se forma a partir de cuatro componentes:

1. Información general: Explique las ventajas que los desarrolladores obtendrán al usar la plataforma, y en algunos casos, proporcione una descripción de arquitectura de la plataforma.
2. Introducción: Ayude al desarrollador a comenzar a trabajar, ya sea por medio de tutoriales paso a paso u otras formas de tutoriales más sencillas.
3. Código de muestra: Proporcione código de muestra con documentación suficiente para que los desarrolladores puedan crear a partir de el.
4. Material de referencia: Proporcione información detallada acerca de cada clase, miembro, función o elemento XML.

Cuando los desarrolladores empiezan a leer acerca de una API, lo primero que necesitan saber es: ¿quién querría usar la API y porqué? Si los desarrolladores no entienden esto, entonces pasarán rápidamente a buscar algo más. Por desgracia, se suele olvidar esta información. Esto es evidente para las personas que desarrollan la API, pero no es así para otros.

Provea ejemplos claros de cuando usaría la API. Si ya cuenta con clientes, o incluso clientes potenciales, úselos como ejemplos reales. Indique las ventajas de la plataforma de software; sería ideal contrastarlo con enfoques ya existentes. Se dará cuenta que los administradores de proyecto generalmente tienen este tipo de información.

La información general es también un buen lugar para explicar la arquitectura general de API. Para ciertos tipos de API (por ejemplo, muchas API de web), la API es suficientemente simple como para que sea innecesario discurrir acerca de la arquitectura. Sin embargo, si está haciendo documentación de algo complejo, con muchas clases y una estructura de herencia, entonces será útil para ayudar a entender a los desarrolladores el hablar en detalle acerca de la arquitectura y proporcionar diagramas para ello.

Introducción

Una vez que los desarrolladores se convenzan de probar su API, lo primero que querrán saber es cómo comenzar a trabajar. En el año 2009, mi compañía (SDK Bridge LLC) llevó a cabo una encuesta sobre documentación y uno de los temas que se tocó constantemente en las respuestas fue que los desarrolladores deseaban ayuda para comenzar (consulte mi artículo “Survey on SDK Documentation” [Encuesta acerca de la documentación de SDK] en tinyurl.com/35l66yk). Esto es fundamental para la adopción: si es difícil para los desarrolladores empezar a trabajar, dejarán esto de lado rápidamente y encontrarán otra manera de cumplir sus metas.

Una excelente manera de introducir a los desarrolladores es por medio de tutoriales. Este enfoque es generalmente mucho más efectivo que el texto descriptivo o los diagramas de la arquitectura. Una tutorial guía a un desarrollador paso a paso por el proceso de creación de una aplicación simple que demuestra como funciona la API. Generalmente empieza con actividades no relacionadas a la programación, tal como configurar su entorno de desarrollo u obtener credenciales de autorización. A partir de allí, dirige al desarrollador a agregar gradualmente más código hasta que puedan demostrar una tarea simple de la API. De ser posible, trate de estructurar su tutorial de manera que los desarrolladores tengan algo que puedan ejecutar y ver sus resultados rápidamente. Después prosiga la tutorial, agregando más características.

Lo más probable es que haya trabajado tan de cerca con su API que haya olvidado como acercarse a ella con una perspectiva totalmente nueva. A medida que trabaje en esta sección, dé lo mejor de sí para tomar distancia y ponerse en los zapatos de un recién llegado.

Escritura de código de muestra

Otro de los temas frecuentes en la encuesta de SDK Bridge fue la importancia de un buen código de muestra. Los desarrolladores aprenden a usar una nueva plataforma empezando con código que tienen seguridad que funciona y a este lo modifican o le agregan elementos. Muchos desarrolladores, si no la mayoría de ellos, aprenden más fácilmente haciendo que leyendo.

Usted probablemente ya sabe como crear buen código de producción. Un buen código de muestra es parecido al buen código de producción, pero también hay algunas diferencias claves. En general, un buen código de muestra debiera seguir estas directrices:

1. La información relevante debe agruparse en el mismo lugar.
2. La claridad es más importante que la eficacia o la solidez.
3. La simpleza es más importante que una IU bonita.

Puede aplicar estas directrices a áreas específicas de software y ver como el código de muestra se compara con el código de producción.

Todos los programadores saben que nunca se deben usar valores codificados de forma rígida en su código. Esos valores se deberían transformar en constantes y ponerlos en alguna parte que sea fácil de encontrar en el caso que alguien quiera cambiarlo.

Resulta que esto se aplica al código de producción, pero no al código de muestra. Debería usar valores codificados de forma rígida para poder agrupar toda la información relevante tan bien reunida como sea posible. Si sigue las prácticas recomendadas para el código de producción y define todas las constantes en el principio del archivo, entonces cuando los desarrolladores miren la primera línea de código que usa la constante, deberán subir hasta el principio del archivo para ver su valor. Esa simple acción puede provocar que pierdan el hilo de lo que estaban pensando. Las cadenas, los números enteros, los valores hexadecimales y otros valores simples deberían codificarse de forma rígida donde sean usados.

Los comentarios son buenos tanto para el código de producción como para el código de muestra, pero en el caso del código de muestra son cruciales. Cada clase, miembro o función debe empezar al menos con una línea de comentario que explique que es o que hace. Debiera usar comentarios en cualquier parte donde el código no sea evidente, especialmente si necesita documentar una solución o algo igualmente inusual. Estos comentarios pueden ser de varias líneas de largo, de ser necesario. Use oraciones completas y no tema ser demasiado extenso.

En general, debiera tener al menos una línea de comentarios por cada cinco o 10 líneas de código. Sin embargo, existen algunas excepciones para esta directiva. El código que no está relacionado con lo que quiere demostrar no necesita tantos comentarios (por ejemplo, el código de IU necesario para mostrar los resultados de su API). Si está escribiendo un fragmento de código breve con sólo unas líneas de código incluido en algo de material de referencia, puede que no necesite comentarios. Si está proporcionando una muestra muy grande, más similar a código de producción, puede ser más práctico reducir el número de líneas de comentarios.

Los nombres de variable, clase, miembro y función deben ser claros, independientemente de que esté escribiendo código de producción o código de muestra. Sin embargo, en el código de muestra, debería ser más enfático en esto que en el código de producción, puesto que la claridad es más importante que la eficiencia. Los nombres largos y difíciles pueden ser problemáticos para el código de producción, pero en general vale la pena usarlos en código de muestra, debido a la mayor claridad. Busque que incluso los nombres de las variables más pequeñas tengan significado y no use, sin importar lo tentador que sea, nombres de variable sin significado, como “foo" o nombres de una sola letra.

La programación orientada a objetos es una de las mejores invenciones de la ingeniería de software. Puede que se sorprenda al descubrir que, aunque es óptimo para el código de producción, en general no lo es para el código de muestra. La razón de esto es que el diseño orientado a objetos distribuye funcionalidad de forma que los datos y las funciones se agrupan, además de usar herencia para reducir o duplicar código. Recuerde, una de las características fundamentales del buen código de muestra es que la información relevante debiera agruparse. Los objetos orientados a objetos tienden a distribuir la información relevante entre varias clases. Por lo tanto, puede que los desarrolladores terminen buscando en una jerarquía de herencia para saber qué hace un método, lo cual sólo sirve para perder el tiempo y hacerles perder el hilo de lo que piensan.

Desde luego, hay excepciones. Algunas API necesitan programación orientada a objetos para funcionar apropiadamente. Puede que las muestras muy grandes que se parecen más a aplicaciones de producción también necesiten ser diseñadas orientadas a objetos. Sólo tenga en cuenta que el usuario desea ver toda la información necesaria en una clase, de ser posible.

Una regla básica de buen diseño de software es encapsular funcionalidad tanto en las funciones como en los métodos. Para el código de producción, esto claramente agrega y reduce el código duplicado. También es bueno para el código de muestra, puesto que generalmente permite crear un bloque de código que los desarrolladores pueden simplemente copiar y pegar, facilitando su uso.

Ocasionalmente, el código de muestra requiere un gran número de líneas de código que no es directamente relevante para la API, pero eso es lo que necesita para obtener una muestra que se pueda ejecutar. En este caso, es una buena idea intentar encapsular las líneas de código irrelevantes en una función o método, de manera que los desarrolladores puedan ignorarlos con más facilidad.

A no ser que la API específicamente provea capacidades de IU que necesite demostrar, debería mantener los elementos de su IU del código de muestra tan simples como sea posible. El código de IU puede tomar mucho espacio y ocultar las líneas importantes de código que desea demostrar. Los desarrolladores no están preocupados de si su ejemplo se ve afinado, ellos sólo necesitan entender como funciona su API.

Si es absolutamente necesario tener un gran número de líneas de código para s IU, entonces empaque ese código en funciones separadas que permitan al desarrollador darle un vistazo o ignorarlo con facilidad.

Finalmente, si bien el control de excepciones es fundamental para que el código de producción funcione bien, en el código de ejemplo puede ocultar el código relevante y generar distracción. Habitualmente es una buena solución no usar control de excepciones, sino que poner un comentario que indique que tipo de excepciones controlar en el código de producción. Sin embargo, hay situaciones en las que ciertos tipos de llamadas deben hacerse siempre con control de excepciones. En esas situaciones, vale la pena colocar las líneas extra de código para mostrar exactamente cómo debe funcionar el control de excepciones.

La figura 1 muestra un ejemplo de una función del código de muestra, que demuestra como hacer una solicitud de REST en C# para un sitio de redes sociales, devolviendo los identificadores de los usuarios que están conectados a los usuarios específicos. En el código de producción, la URL del extremo de REST se almacenará como una constante, junto con otras URL relevantes. Sin embargo, en el código de muestra, es mejor colocar esta información donde sea más probable que lo vean los desarrolladores y que hagan la conexión a su rol en la función. Observe también que se sugiere el control de excepciones, pero no está implementado. El procesamiento de XML se eliminó del ejemplo para mantener la brevedad.

Figura 1 Ejemplo de código de muestra

/// <summary>
/// Returns an array of user IDs for users that 
/// are connected to the specified user. Note that 
/// this is a simple, synchronous way to obtain the data.
/// </summary>
/// <param name="userId">The ID of the specified user.</param>
/// <returns>An array of user IDs that are connected to 
/// the specified user.</returns>

public int[] GetConnectedUserIds(int userId) {
  // Create variable to hold the returned IDs
  int[] connectedIds;

  // Construct a URL using the userId and the authorization token
  string url = 
    "http://webservices.contoso.com/users/connections?userid=" + 
    userId.ToString() +
    "&token=" + 
    authorizationToken;

  // Create the Web request using the url
  HttpWebRequest request = 
    WebRequest.Create(url) as HttpWebRequest;
 
  // Get the response
  using (HttpWebResponse response = 
    request.GetResponse() as HttpWebResponse) {

    // Read the response XML
    StreamReader reader = 
      new StreamReader(response.GetResponseStream());
    string xmlResponse = reader.ReadToEnd();

    // Process XML to extract user IDs for connected users 
    // and responseStatus
    ...

    if (responseStatus != "ok") {
      // Handle errors here
      ...
    }

    reader.Close();
  }

  return connectedIds;
}

Material de referencia

El material de referencia generalmente es la parte más significativa de la documentación de API. Se necesita información detallada acerca de qué es y cómo se usa cada clase, miembro, función, elemento XML, etc. Como mínimo, el material de referencia debe tener:

• una descripción breve
• una descripción de todos los parámetros y devoluciones de valores
• cualquier comentario importante que ayude al desarrollador

De haber más tiempo y presupuesto, agregue la siguiente información:

• excepciones que sea necesario tomar en cuenta
• vínculos a otra información general o temas de referencia
• un fragmento de código de muestra, idealmente desde el código de muestra que ya escribió

Una buena documentación de referencia tiene un estilo consistente en todo el texto. Algunas veces las directrices de estilo ya existen, pero por lo general es tarea suya hacerlos. La figura 2 proporciona algunas directrices generales para las descripciones breves.

Como ejemplo, considere las descripciones indicadas en la figura 3 para la clase Button (botón) de Microsoft .NET Framework. Esto está extraído directamente de la documentación de SDK en MSDN.

Figura 2 Estilo de documentación de referencia

Tipo	Directriz	Ejemplos
Clase	Empiece con una palabra como “Representa”	“Representa un album de fotos de usuario".
Métodos y funciones	Comience con un verbo	“Devuelve el número de contactos al área especificada”. “Pone al vídeo en pausa”.
Propiedades	Use un sustantivo o comience con verbos del tipo de “Obtiene” u “Obtiene y configura”.	“Las tareas del usuario”. “Obtiene y configura una colección de las tareas del usuario”.
Eventos	Empiece con una frase como “Se produce cuando” u “Ocurre cuando”	“Se produce cuando se recibe la respuesta del servidor”.
Elementos XML	Use una frase sustantiva	“El código postal de la ciudad”.
Valores Booleanos	Para propiedades booleanos, empiece con “Indica si”; para valores booleanos devueltos en métodos y funciones, comience con “Es devuelto si”	“Indica si el control es visible”. “Se devuelve si se intersecan dos regiones”.

Figura 3 Ejemplo de documentación de referencia

Clase o miembro	Tipo	Descripción
Descripción de clase	Clase	Representa un control de botón de Windows.
Constructor de button (botón)	Constructor	Inicializa una nueva instancia de la clase Button (Botón).
Foco	Método	Configura el foco de entrada para el control.
Visible	Propiedad	Obtiene o configura un valor que indica si se muestra el control y todos sus controles secundarios.
Haga clic en	Evento	Ocurre cuando se hace clic en el control.

API de web

El número de API de web ha crecido rápidamente en los últimos años, de manera que puede ser útil reflexionar acerca de la diferencia entre las API de web de las API locales. El Software como Servicio se está volviendo un modelo de negocios popular y las empresas están descubriendo que sus clientes más grandes desean poder usar sus servicios directamente desde sus propios sistemas. Esto significa que el proveedor de servicios necesita hacer una API pública a la que los clientes puedan llamar.

(Una nota acerca de la terminología: uso el término “API local” para describir el tipo de API habitual que ha existido desde antes de la web. Técnicamente, estas API pueden ser llamadas a procedimientos remotos, por lo tanto no son locales; técnicamente las API de web se pueden llamar desde un servidor que es el mismo equipo que el del cliente, por lo tanto son locales. Sin embargo, en muchas ocasiones, las API de web, las cuales usan protocolos estándar como HTTP, se usan de forma remota y otras API se usan localmente).

Dado que las API de web son relativamente nuevas, no existe un estándar acerca de cómo se ve su documentación. La calidad de la documentación de API de web varía significativamente. A veces está bien organizada y es completa, en otras ocasiones es la información mínima arrojada a una wiki. Si escribirá documentación de API de web, vale la pena pasar invertir algo de tiempo en ver cómo varias compañías han documentado sus API, de manera que tenga una buena plantilla que seguir. Por ejemplo, Twilio, una plataforma para aplicaciones de voz y mensajería, tiene un excelente ejemplo de documentación de REST, la cual puede encontrarse en twilio.com/docs. Es de esperar que, con el tiempo, la industria defina una pequeña cantidad de plantillas efectivas.

De alguna manera, la documentación de API de web es más crítica que la documentación de API local, puesto que puede ser más complicado para los desarrolladores el experimentar con API de web para entender como funciona. Puede que los desarrolladores tengan limitaciones (cuotas) en cuanto a la cantidad de veces que pueden hacer una llamada, puede que su experimentación afecte a un sistema activo o puede ser difícil emular condiciones específicas, como cuando el servidor está sometido a una gran cantidad de trabajo.

Como se mencionó anteriormente, los desarrolladores necesitan códigos de muestra. Una de las características poderosas de las API de web es que son independientes de plataforma y lenguaje. Desafortunadamente, esto significa trabajo extra al crear código de muestra. Puede que termine escribiendo código de muestra en Python, Ruby, Java, C#, etc. Intente descubrir lo que sus clientes usan más y enfóquese en los lenguajes que son más importantes para ellos.

Las dos tecnologías más comunes para las API de web son SOAP y REST. SOAP tiene un formato de definición (Lenguaje de descripción de servicios web o WSDL) que es un excelente punto de partida para la documentación de referencia, al contrario de REST. Las llamadas de HTTP de muestra y los archivos XML/JSON son útiles para ilustrar en ambas tecnologías como funcionan, pero no son suficiente. Los ejemplos debieran ser seguidos por tablas que describen cada elemento, como también su formato de fecha.

Por ejemplo, puede que no baste describir un parámetro como una cadena. ¿Hay caracteres especiales que no puede controlar? ¿Hay limitaciones de largo? Si un elemento XML es una fecha, debe especificar el formato de la fecha. Si se usa hora, debe especificar la zona horaria.

Además, necesita explicar como se manejan los errores. Esto puede variar para los distintos formatos con los que su API es compatible. Si la API usa códigos de respuesta de HTTP para marcar errores, se deben documentar tales códigos. La documentación de error debe explicar la razón por la que un error ocurre y cómo solucionar el problema.

Frecuentemente se necesita autenticación para API de web y esto necesita documentarse en detalle también. Si los desarrolladores necesitan claves de API, asegúrese de darles instrucciones paso a paso acerca de cómo obtenerlas. Además, no se olvide de que las API de web están creadas en base a HTTP, el cual es un protocolo tremendamente rico. Puede que tenga información relacionada con HTTP que necesite documentación, como el almacenamiento en memoria caché, tipos de contenido y códigos de estado.

Las API de web son suficientemente nuevas como para que estemos aún en una etapa donde buscamos la mejor manera de documentarlas. Espere que en los próximos años esto se estandarice.

Publicación

Hasta ahora, me he enfocado en el contenido, pero también necesitará publicar la documentación, de manera que los desarrolladores puedan leerla. En general, los desarrolladores esperan ver documentación basada en web con hipervínculos en lugar de archivos planos, tales como un PDF. Hay varias maneras de hacer llegar su documentación a la web.

Si la API es pequeña, puede que lo más simple sea crear archivos HTML. Use CSS para la apariencia coincida con la del sitio web de su compañía.

Las wikis proporcionan una estructura para API más complicadas. Las wikis también le permiten actualizar o agregar documentación fácilmente a medida que pasa el tiempo, sin necesidad de tener acceso a otras herramientas o servidores. Además, los aspectos de colaboración de grupo de wikis permiten la contribución de equipos enteros, incluso de los usuarios. Sin embargo, armar una wiki y esperar que sus desarrolladores y usuarios escriban los documentos no es una estrategia de documentación de API muy viable.

Hay muchos motores de wiki de código abierto disponibles y se están volviendo populares para la documentación de API, tales como MediaWiki (mediawiki.org/wiki/MediaWiki), que está basado en PHP, y TWiki (twiki.org), que está basado en PERL.

Las herramientas de documentación comerciales, como Madcap Flare (ver madcapsoftware.com/products/flare) y Adobe RoboHelp (ver adobe.com/products/robohelp) están diseñados principalmente para documentación de usuarios finales, pero se pueden adoptar con facilidad para la documentación de API. Estos proporcionan una IU simple para ingresar información y proporcionan un aspecto más refinado que una wiki. Estos pueden generar documentación tanto en formato web como de archivo plano desde la misma fuente.

Los servicios de colaboración en línea, tales como PBworks (pbworks.com) y MindTouch (mindtouch.com) también se usan para documentación de API. Además de las características colaborativas de las wikis, estas proporcionan características adicionales, como hospedaje, un control de acceso muy fino y capacidades de scripting. Estos servicios generalmente exigen una cuota de suscripción para el uso comercial.

¡Envíelo!

Una buena documentación de API es crucial para la adopción de su plataforma y para reducir el número de llamadas a soporte técnico que recibe su compañía. Si puede convencer a su administrador para que contrate a un escritor técnico con las capacidades adecuadas, hágalo. Pero si no puede, siga la guía de este artículo.

Su documentación debe contar con información general, ayuda para empezar, código de muestra y material de referencia. En la información general, asegúrese de explicar la razón por la que se debe usar su plataforma. Elabore tutoriales para ayudar a los desarrolladores a empezar a trabajar. El código de muestra debe enfocarse en la claridad y en la simpleza, y no siempre debe apegarse a los mismos principios de escritura de código que el código de producción. Su material de referencia debe ser detallado y consistente. Hay varias herramientas en línea que le ayudarán a publicar su documentación en la web.

Ahora, ¡empiece a escribir!

Peter Gruenbaum  empezó su camino como médico, pero se convirtió en desarrollador de software y trabajó en tecnologías tan diversas como Tablet PC, realidad aumentada, diseño asistido por PC y simulación quirúrgica. Fundó SDK Bridge LLC para reunir su amor por la tecnología y el escribir, donde escribe y enseña acerca de tecnología.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: John Musser (ProgrammableWeb) y Eugene Osovetsky (WebServius)