usar servicios saber restful qué otro mejor ejemplos cuando como web-services rest soap rpc

web-services - servicios - web service soap y restful



¿Ejemplos de las mejores API web de SOAP/REST/RPC? ¿Y por qué te gustan? ¿Y qué les pasa? (8)

En mi empresa estamos comenzando a ramificarnos en API web para acceder y actualizar nuestros datos; inicialmente para socios pero luego para el público en el futuro. Por el momento, la forma en que se verá la API (por ejemplo, SOAP, REST, RPC) está completamente abierta y aún no hemos tomado ninguna decisión, por lo que estoy interesado en ejemplos de API web que las personas piensan que son buenas y por qué piensan ese.

Lo que me interesa son las opiniones de personas que usan diferentes idiomas (es probable que ofrezcamos la API a personas que utilizan varias plataformas, particularmente .NET, Java, ActionScript y JavaScript) sobre las API web que crees que son buenas. ejemplos, y con los que has tenido buenas experiencias.

Algunos puntos que me gustaría cubrir:

  1. ¿Prefiere los servicios de tipo SOAP o los de estilo REST / RPC? Sospecho que las personas con soporte de plataforma (por ejemplo, .NET, Java) preferirán SOAP y las personas que usan idiomas sin soporte de plataforma preferirán las otras, pero me gustaría validar esa suposición.

  2. ¿Le importa si una API es RESTful o si se trata de un antiguo GET / POST HTTP de estilo RPC? Si es así, ¿por qué te importa? ¿Es más importante que una API se describa a sí misma correctamente (es decir, no pretenda ser RESTful si es de estilo RPC) que si en realidad es una de las dos?

  3. Necesitamos verificar quién está usando el servicio. He estado buscando en la autenticación de Amazon S3 que utiliza un identificador público y un token privado que se utiliza para actualizar los parámetros de la solicitud en un token de verificación (esto también es similar a flickr). ¿Ha utilizado este tipo de autenticación anteriormente y cómo lo hizo? ¿Hay algún algoritmo hash que te resulte problemático (es decir, no compatible con tu plataforma)? ¿Prefiere enviar el hash en un encabezado HTTP o en el URI?

  4. ¿Cómo deben manejarse las versiones? ¿Es una buena idea tener un subdirectorio /v1/ type para que las futuras versiones puedan agregarse al mismo tiempo, o hacer algo diferente como tener la versión en la carga útil o consulta? ¿Cuánto tiempo esperaría que fuera compatible con una versión de una API que había construido? (Es decir, si se introdujera v2, ¿cuál sería su expectativa durante la vida de v1)?

Además, cualquier otra opinión y puntos para cubrir sería útil.

Me mantengo vago sobre el tipo real de API que estamos implementando, ya que busco orientación general en términos de lo que la gente piensa que son buenas API y mecanismos de implementación, por lo que esta publicación y sus respuestas serán útiles para más personas. en el futuro.

Nota: He buscado y no puedo encontrar una pregunta genérica sobre esto, todas parecen específicas para un cierto tipo de API, pero si es un duplicado, házmelo saber. Además, si se tratara de wiki de la comunidad (creo que las personas deberían obtener un crédito por las respuestas, así que no lo hice), por favor avíseme y lo cambiaré para que así sea.

Aquí está mi opinión.

  1. Aunque desde el punto de vista de Java, en realidad prefiero el RESTO. El sobre SOAP con múltiples espacios de nombres y su estructura compleja es abominable. Intenta resolver problemas en su mayoría imaginarios, y no resuelve nada de manera eficiente. Lo único que SOAP me ha parecido útil es que tiene estándares de autorización y errores. Por otro lado, ambos podrían resolverse mucho más fácilmente al incluir cuatro atributos estándar en el elemento raíz de XML: nombre de usuario, contraseña, código de error, errorDescription.

  2. La buena descripción y documentación de la API es, de hecho, todo lo que importa. La diferencia entre REST y SOAP en el marco maduro es principalmente en unas pocas líneas de configuración.

  3. Para SOAP, envíe hash como parte de la seguridad de SOAP; para REST, me gusta empaquetar todo en payload y evitar los encabezados HTTP para la autenticación. Sin embargo, tengo solo motivos subjetivos, ya que tuve que luchar con frameworks que no exponen fácilmente los encabezados HTTP.

  4. Mi preferencia personal es tener diferentes URI para diferentes versiones de protocolo. En mi experiencia, esto le da más flexibilidad en las versiones más nuevas, y los clientes antiguos que se conectan a versiones no compatibles de un protocolo dejan de funcionar inmediatamente y por razones obvias. Además, a veces puede asignar una versión anterior de la aplicación al URI antiguo para evitar tener un código de soporte heredado en la nueva versión del servidor.

    En cuanto a cuánto tiempo soportas la versión anterior del protocolo ... idealmente, siempre y cuando tengas clientes que lo usen. Esto es más un negocio que una decisión técnica. Debe admitir al menos una versión de protocolo anterior. Por lo general, es de su interés impulsar a los clientes hacia una nueva versión para reducir los costos de soporte heredados; desde el lado del cliente, la nueva versión debería significar nuevas características, mejor protocolo y algún tipo de incentivo comercial adicional (si las nuevas características por sí solas no son suficientes).

El enfoque RPC también es una buena opción. Reduce los gastos generales y proyectos como Ice, Google Protocol Buffers y Apache Thrift facilitan el desarrollo de servicios basados ​​en RPC.

Si no tiene que proporcionar una API basada en web, entonces RPC también puede ser una opción que desee explorar.

En mi humilde opinión, todo depende de qué tipo de aplicaciones estés ofreciendo. Si está haciendo transacciones importantes, grandes, entonces definitivamente vaya con SOAP (WS "estrella de la muerte" como lo llaman). Pero si está ofreciendo aplicaciones sociales, entonces vaya con REST, ya que es más simple y se adapta mejor al pirateo público.

REST, si se realiza correctamente, es fácil de entender (modelos HTTP), directo (orientado a recursos) y prácticamente todos los lenguajes de programación (XML) pueden analizarlo.

Si no puede decidirse eventualmente, puede implementarlos todos. En estos casos, es útil observar cómo lo han hecho otros. Te recomiendo el eXist código abierto XML Native Database eXist que ofrece los tres tipos de interfaces que te gustan.

Vería lo que hace Amazon - http://aws.amazon.com/ - los chicos que ganan dinero con esto obviamente habrán aprendido más lecciones que cualquier otra persona.

Me gustaría ver otras API: salesforce.com y Microsofts CRM api fue bastante interesante. Twitter también tiene una batalla de REST api endurecido.