Una API web pública: ¿Qué prefieren los desarrolladores a consumir?

Question

Tenemos un montón de datos que nos gustaría exponer al mundo alojado en un sitio web asp-net.mvc. Me gustaría asegurar que lo entreguemos utilizando una tecnología que sea fácil de implementar para los desarrolladores finales y no vinculada a ninguna plataforma en particular, en lugar de utilizar tecnología que no sea popular/incompatible con los desarrolladores.

El tipo de solicitudes que esperamos son principalmente para recuperar resultados de búsqueda (no muchos parámetros), pero al igual que nos gustaría poder proporcionar búsquedas de catálogos y similares, que pueden ser más complejos.

Teniendo esto en cuenta, ¿cuál es el medio preferido para hacer esto?

Answer 1

Windows Communication Foundation se pueden usar para crear servicios SOAP (excelente si sus consumidores son negocios, usando Visual Studio/.NET o Java) o servicios REST (para personas en otras plataformas). Esos son los medios preferidos para exponer las API públicas.

Si desea la máxima exposición, probablemente sea mejor utilizar el enfoque REST, ya que es más fácil de consumir en idiomas "web" como JavaScript. Microsoft tiene extensive resources al armar una API REST usando WCF.

Sinceramente, para los tipos de peticiones que usted dice que necesita para manejar, que todos parecen ser mirando hacia arriba de datos en lugar de modificar que, la diferencia es casi trivial - puede cambiar de jabón para descansar simplemente cambiando algunos atributos/opciones de configuración e incluso podría alojar ambos al mismo tiempo usando muy poco código adicional. Siempre y cuando te apegues a WCF y no uses tecnología obsoleta como ASMX/WSE, entonces estarás bien.

Razones para utilizar RESTO:

• consumibles desde casi cualquier lugar (incluyendo JavaScript, lectores de RSS, etc.);
• Es popular (en uso por Google, Twitter, etc.)
• es compatible con muchos formatos de datos diferentes (JSON, Atom, etc.)

razones para utilizar el jabón:

• estandarizada protocolo de seguridad (cifrado, no repudio, etc.)
• Las transacciones distribuidas
• Message Queuing

No es una lista exhaustiva, pero debería darle una idea de quiénes son los mercados objetivo para cada uno. Si está alojando un sitio muy abierto, muy público, diseñado para ser consumido por todos, vaya a REST. Si el servicio es parte de un sistema comercial y necesita garantizar la confiabilidad, seguridad y consistencia de los datos, querrá ir con SOAP. Elija la tecnología adecuada según su mercado objetivo.

Answer 2

Crea una API RESTful. Como desarrollador que a menudo consume servicios web, es lo que esperaría y preferiría.

Muchos servicios populares (digg/twitter/netflix/google) se están moviendo a REST sobre SOAP, por lo que sería aconsejable hacer lo mismo.

Answer 3

Si crea una API REST, también debe crear un archivo WADL. Es WISDL para REST. Aún no cuentan con un buen soporte, pero no son difíciles de crear y se volverán más útiles a medida que aumente el soporte.

Answer 4

Querrá ver odata. Mira odata.org y live.visitmix.com/videos Esto te dará acceso REST, soporte de metadatos como SOAP, interoperabilidad con toda la pila de la oficina y si estás usando WCF Data Services puedes implementarlo en cuestión de horas , días como máximo.

Eche un vistazo a netflix.com, lo han hecho bien (en mi humilde opinión).