norma - que es una api en java

API de lenguaje agnóstico

Question

Estoy planeando poner un servicio web o algún otro servicio expuesto a través de Internet. Me gustaría crear una API para que las aplicaciones interactúen con este servicio. Me gustaría que la API se pueda utilizar en diferentes idiomas, como Java, C ++, C # o PHP. ¿Cómo puedo mantener una base de código para mi API, pero distribuir buenos binarios empaquetados para todos estos idiomas? Además, es posible que desee considerar que esto también podría ser una plataforma cruzada.

Actualización 1

Estoy empezando a trabajar en los servicios web, pero creo que uno de los puntos clave es que muchas herramientas admiten la implementación de clientes según la descripción del servicio, como WDSL. No he entregado ningún software del lado del cliente con nada de lo que he hecho, espero que cualquier usuario pueda construir sus propios clientes adecuados a sus necesidades. --La ​​respuesta del bagre

No me opongo a convertirlo en un servicio web directo, sino a entregar un archivo WSDL. Pero, ¿y si quiero que la API del cliente haga algo de lógica, encriptación, comprobación de errores, etc.?

Actualización 2

En cuanto a esperar que el cliente que está usando su API haga algo, ¡no puede! No hay nada que puedas hacer para garantizar que el consumidor de la API haga lo correcto. Es por eso que el manejo robusto de errores es tan importante. Debe verificar y verificar dos veces cualquier cosa que provenga del cliente. Siempre debes sospechar de ello e incluso asumir que es malicioso. Realmente no hay una buena forma de evitar ese hecho. --Ryan Guill''s Answer

Mi idea original era crear un archivo DLL o ensamblado en .NET, luego el cliente realiza llamadas a este código que se ejecuta desde el lado del cliente. Este código puede comunicarse a través de cualquier protocolo de comunicaciones con el servidor, pero mi API se estaría ejecutando en su casilla. Supongo que REST no logra esto. Parece que en REST todo sigue siendo una publicación HTTP. Es casi servicios web sin jabón.

Actualización 3

He aceptado la respuesta de Ryan Guill. Creo que la idea general es que necesito exponer un servicio de red de algún tipo, con la barrera más baja para el cliente. De esa forma, cualquiera puede conectarse. Entonces solo tengo que ejecutar todo mi código en el servidor. Eso parece ser aceptado como el único deseo de lograr realmente la independencia de la plataforma y el lenguaje que busco.

Gracias por toda la entrada.

Answer 1

Estoy empezando a trabajar en los servicios web, pero creo que uno de los puntos clave es que muchas herramientas admiten la implementación de clientes según la descripción del servicio, como WDSL.

No he entregado ningún software del lado del cliente con nada de lo que he hecho, espero que cualquier usuario pueda construir sus propios clientes adaptados a sus necesidades.

Si revisas la API de Flickr como lo sugiere una de tus otras respuestas, no creo que proporcionen el código del lado del cliente, otras personas han creado y contribuido con las cosas del lado del cliente.

Answer 2

Respuesta simple, no.

Respuesta compleja: crear una API y compilarla en un dll COM. Luego, solo crea el código contenedor para los idiomas que no pueden manejar eso.

Respuesta simple n. ° 2: hacer que el servicio original sea tan trivial o tan universalmente aceptable que no requiera una API (generalmente lo implementé mediante sondeos en la base de datos del servidor.) Feo, pero cualquier lenguaje que pueda acceder a una base de datos puede utilizar el programa).

Answer 3

Sugiero que escriba la API en el lenguaje de programación Haxe para que el código fuente se pueda traducir directamente a todos los lenguajes de programación que mencionó. El lenguaje de programación Haxe se puede traducir (o "trans compilar") a todos los lenguajes de programación que mencionó en la publicación original, así como a algunos otros.

Answer 4

Utilizaría una API REST, similar a la forma en que funciona la API de Flickr: http://flickr.com/services/api/

Es bastante simple de crear y mantener, los mayores inconvenientes son que se necesita mucha documentación (pero prácticamente de la misma forma que se hace con una API tendrá este problema) y ese manejo robusto de errores es imprescindible.

Pero en mi opinión, es la mejor manera de crear una API que sea la más cercana al lenguaje cruzado / multiplataforma.

Más información aquí: http://www.xfront.com/REST-Web-Services.html

Actualización : el remitente agregó lo siguiente a la publicación:

No me opongo a convertirlo en un servicio web directo, sino a entregar un archivo WSDL. Pero, ¿y si quiero que la API del cliente haga algo de lógica, encriptación, comprobación de errores, etc.?

Personalmente, no me gusta usar SOAP (usando un WSDL). Hay una gran cantidad de gastos indirectos para usar SOAP, tanto en el servidor como en el cliente. Creo que es por eso que ves cada vez más API públicas escritas usando REST. Realmente reduce la barrera de entrada al mínimo común denominador, permitiendo que cualquier cosa que pueda usar HTTP básico (GET y POST (también PUT y DELETE para la forma "correcta" de hacerlo)) use la API.

Algunos ejemplos más de API públicas escritas usando REST: twitter , vimeo , Google

En cuanto a esperar que el cliente que está usando su API haga algo, ¡no puede! No hay nada que puedas hacer para garantizar que el consumidor de la API haga lo correcto. Es por eso que el manejo robusto de errores es tan importante. Debe verificar y verificar dos veces cualquier cosa que provenga del cliente. Siempre debes sospechar de ello e incluso asumir que es malicioso. Realmente no hay una buena forma de evitar ese hecho.

Actualización 2: el remitente agregó lo siguiente a la publicación:

Mi idea original era crear un archivo DLL o ensamblado en .NET, luego el cliente realiza llamadas a este código que se ejecuta desde el lado del cliente. Este código puede comunicarse a través de cualquier protocolo de comunicaciones con el servidor, pero mi API se estaría ejecutando en su casilla. Supongo que REST no logra esto. Parece que en REST todo sigue siendo una publicación HTTP. Es casi servicios web sin jabón.

Ciertamente puede hacer esto, pero eso solo funcionará para los lenguajes .NET, lo que significa que sus beneficios multiplataforma e interpares están fuera de la ventana. Y aún así, al final, ¿realmente estás impidiendo algo? El desarrollador usará su API remota o su DLL o ensamblado local. De cualquier manera, él tendrá que saber cómo usarlo y usarlo correctamente, de lo contrario, lanzará un error. Todo lo que realmente estás haciendo es cambiar de dónde salen los errores. Lo cual puede ser importante para usted (de ser así, mencione por qué) pero realmente no está cambiando nada en la ecuación.

Pero tiene cierta razón al decir que REST es algo así como servicios web sin SOAP. Técnicamente, REST también es servicios web, es solo que los servicios web han llegado a significar SOAP en general. Realmente es una forma diferente de lograr lo mismo. Sin embargo, las mayores diferencias son que requiere más programación y pensamiento de su parte (y potencialmente más programación del lado del cliente), pero usted cambia eso por robustez, menos sobrecarga tanto para el consumidor como para el servidor y la audiencia más amplia posible para la API . Realmente es el denominador común más bajo.