web services - verbos - Protocolo de publicación Atom en la vida real

web service soap

Question

Sé que algunos grandes jugadores lo han aceptado y, de hecho, están exponiendo algunos de sus servicios de forma compatible con las aplicaciones. Sin embargo, no he encontrado muchos otros jugadores (más pequeños) en este campo. ¿Conoces alguna aplicación / servicio web que use APP como su protocolo API público? ¿Cuál es tu opinión sobre AtomPub? ¿Tienes alguna experiencia práctica al usarlo? ¿Cuáles son sus limitaciones y desventajas? ¿Prefiere AtomPub como su estilo REST o tiene alguna otra favorita? ¿Y por qué?

Lo sé, estas son muchas preguntas, no solo una. Sin embargo, lo que me interesa aquí es simple: ¿cómo llegó al mercado el estándar APP y, en particular, cómo se ve con su adopción entre los desarrolladores web?

Answer 1

Mi propia investigación hasta el momento:

• Wordpress admite AtomPub como su protocolo API desde la versión 2.3
• GData es probablemente el tiro más grande en el campo AtomPub hasta el momento
• Habari : el nuevo y prometedor sistema de blogs promueve la aplicación como una de sus características principales
• BlogSvc.net - un servidor AtomPub, motor de blog para plataforma .NET, escrito en C #
• Jangle : un proyecto de código abierto diseñado para facilitar el acceso de la API a los sistemas bibliotecarios

Answer 2

También hay mod_atom , un módulo Apache que almacena entradas en el sistema de archivos.

Answer 3

La última vez que revisé (alrededor de 2007), Atompub fue bastante complejo de implementar. Si bien puedes combinar algo que emite alimentaciones Atom válidas durante el almuerzo, la implementación de AtomPub fue una empresa bastante grande.

Eso podría haber cambiado debido a mejores bibliotecas y herramientas, pero aún así podría ser demasiado complejo para ser implementado por partes más pequeñas simplemente porque es genial.

Y la falta de aplicaciones de cliente AtomPub asesinas ejerce poca o ninguna presión sobre los operadores de servidores para que ofrezcan una interfaz AtomPub.

Answer 4

La compañía para la que trabajo está desarrollando muchos servicios RESTful. Sin embargo, ninguno de ellos expone las API públicas (en el sentido de que todos los servicios son consumidos internamente por nuestros propios clientes). La razón por la que optamos por el estilo arquitectónico REST fue que queríamos que nuestros servicios fuesen fáciles de consumir y, lo que es más importante, escalaran bien.

Desde mi propia experiencia práctica, he llegado a la conclusión de que el formato de sindicación HTTP + ATOM es una buena idea, siempre que desee mantener las cosas flexibles (en términos de diferentes modelos de contenido, adjuntar y extender metadatos asociados con cargas útiles, análisis uniformes, etc.) . ATOM se asegura de que todos interpreten la carga útil de manera uniforme sin ningún margen de ambigüedad.

Sin embargo, si uno no tiene tales requisitos complejos o no prevé tales requisitos, entonces el formato ATOM podría ser un poco sobrecargado. (Por ejemplo, elementos como Autor, Título, etc. tienen más sentido en el mundo de los blogs / RSS y pueden no tener sentido en el dominio de su problema particular).

Además, si el objetivo es simplemente serializar estructuras de datos en un extremo y reconstruirlos en el otro extremo, entonces la mayoría de los marcos web (como WCF) tienen formatos personalizados que son más atractivos.

Entonces, en mi opinión, ATOM Pub es bueno si necesita flexibilidad en términos de representación de datos y si el campo de juego es enorme con diferentes tipos de clientes.

Sin embargo, si tiene un buen conocimiento de los posibles clientes y los patrones de uso del servidor / cliente, entonces los formatos personalizados pueden ser una buena idea.

Si el cliente está basado en navegador, los formatos como JSON son muy atractivos.

Espero que esto responda a su pregunta.