with tutorial started net example español crear consumir asp rest api-design asp.net-web-api

rest - tutorial - ¿Cuál es el estándar de oro para las API de sitios web? Twitter, Flickr, Facebook, etc.



web api rest c# (15)

Parece que hay dos categorías de API para sitios web en la actualidad.

  1. API que permiten extender la funcionalidad del sitio como Facebook, Myspace, etc. Estas API parecen ser muy diversas.

  2. API que permiten la interacción con la funcionalidad del sitio existente como Twitter, Flickr, etc. Todos estos afirman estar basados ​​en REST, pero en realidad son simplemente "datos a través de HTTP".

Si estuviera creando un sitio web que permitiera tanto la extensión funcional como la interacción externa, ¿qué API existentes usaría como modelo de referencia?

AtomPub es el estándar de oro porque fue diseñado por algunas de las mentes más brillantes de Internet. No puede ir demasiado mal usando iit como base. Eso es lo que hacen google y msft.

Con respecto a la lista de grandes API de Jeff: estoy bastante seguro de que lo común no significa "estándar de oro" .

No es necesario mantener una lista manual de API generalizada. Para obtener una lista, consulte http://www.programmableweb.com/apis/directory/1?sort=mashups .

Como me gusta el REST como un estándar poco estricto, diría que una API es "Dorada" cuando tiene sentido y es intuitiva .

... todo tiene más sentido para mí y está bien pensado (como Brian ya señaló).

En mi trabajo diario actual también trabajo mucho con OpenSocial, donde los URI se sienten muy naturales, pero también extienden el estándar REST a su manera.

Si te gusta estricto y seguro, usa SOAP.

Creo que la mejor manera de responder es enumerar las características de las buenas API web en lugar de citar ejemplos. Si te gustan las API de Twitter / Facebook / etc, ¿qué aspecto de estas API encuentras atractivo?

Voy a tomar una primera puñalada:

  1. API bien documentadas, incluidas las restricciones y las políticas de uso. Esto permite un desarrollo rápido con confianza, en lugar de adivinar qué significan los parámetros y qué valores de retorno son.
  2. API agnósticas de tecnología / lenguaje. Las buenas API deberían ser fácilmente utilizables, proporcionando la misma funcionalidad, en una amplia gama de idiomas y plataformas.
  3. API bien respaldadas Siempre hay errores. Los mantenedores receptivos resultan en más API utilizables
  4. Conjuntos de API en capas. Cuando las API tienen capas ordenadas, una amplia gama de desarrolladores puede consumir las piezas que necesitan sin tener que tirar de capas extrañas. Como ventaja, obliga a los creadores a pensar mucho sobre API limpias y componentes.

Por favor agregue más a los comentarios.

Dependerá de cuál sea tu público objetivo. Si se trata de tiendas .net, entonces el jabón probablemente esté bien enfocado de otro modo en REST ya que tiene una barra de entrada mucho más baja. Desde allí, consulte las API de sitios web que se dirigen a las mismas personas que le gustaría. De esta forma tu API se sentirá familiar.

Después de haber trabajado con algunos, voy directo a ello

  • Facebook

    • BUENO: limpio y relativamente consistente. Se desempeña bien y la mayoría de las cosas lógicamente tienen sentido. FQL es bastante limpio. Opciones XML y JSON. Sin preconcepcion de formato de respuesta que no sea lo que realmente necesita
    • MALO: cambia a menudo y sin previo aviso. las bibliotecas ''oficiales'' de API son bastante atroces. la documentación de muchas llamadas es pobre o faltante. Autenticación no estándar (¿algunos pueden llamarlo bueno?)

  • Mi espacio

    • BUENO: estándares abiertos (autenticación OAuth, punto final Opensocial)
    • MALO: a menudo roto. El uso de oauth es muy no estándar y rompe la mayoría de las bibliotecas de los clientes. las bibliotecas oficiales de los clientes son terribles.

  • Photobucket (descargo de responsabilidad: escribí el lado del servidor de la API de Photobucket)

    • BUENO: autenticación estándar abierta (oauth). xml, json, incluso php serialized array format como parámetros de respuesta. fiel REST (get / put / delete / post en urls ''noun'').
    • MALO: no muchas bibliotecas de clientes. Desafíos arquitectónicos con las bibliotecas Oauth estándar (los usuarios viven en subdominios, las llamadas se deben realizar en el subdominio, por lo que url tiene que cambiar).

  • Gorjeo

    • BUENO: bastante consistente (aunque api vs búsqueda api tiene diffs). Buena práctica de REST. Autenticación de OAuth, así como compatibilidad con Basic de la educación infantil.
    • MALO: tasa de error (bastante consistente con el resto de Twitter). Formato impar de algunos valores devueltos (como su formato de fecha).

Características ideales

  • No me venden en RESTO ''estricto''. PUT y DELETE causan problemas en algunos idiomas de los clientes. GET y POST parecen ser suficientes con los ''verbos'' apropiados. Además, los nombres de funciones similares a RPC están bien para mí siempre que sean lógicos e incluso parte del URI. En ese caso, el objeto IDS aún necesita ser muy consistente.
  • Autenticación / autorización estándar. Basic / Digest puede estar bien, pero soy un fanático de OpenID / oAuth (o WRAP si quieres obtener un margen de ataque). Hacerlo por su cuenta significa que debe explicar el 100% y, potencialmente, escribir bibliotecas cliente para todos.
  • Tipos de datos estándar. Asegúrese de ser coherente con sus tipos de datos (ya sea ''verdadero'' o 1, no con alguna combinación), y respalde los estándares más genéricos. Fecha y hora debe ser ISO8601. La geolocalización debe ''parecerse'' a GeoRSS, etc. Debería poder crear un validador estricto XSD / relaxNG / whatever para sus tipos de devolución. Espere los mismos estándares de sus entradas.
  • Estructura de retorno simple. hay algún beneficio para XML-RPC / JSON-RPC en que usted sabe lo que está recuperando, pero en cualquier caso, si no puedo analizar fácilmente su tipo de retorno con JSON o algo así como SimpleXML de PHP y esencialmente serializarlo en un formato consistente hash, voy a estar enojado.
  • Soporte extensión / expansión sin rotura. No codifique en una esquina y dificulte agregar a su API. Trate de tomar buenas decisiones de antemano que no cambiará constantemente.
  • ¡Documentación! Asegúrate de que sea bueno y explica todo. Incluso entonces no será lo suficientemente bueno, así que asegúrese de tener tiempo dedicado para trabajar en él y un foro de apoyo o lo que sea para mantenerlo actualizado.

Entonces eso dicho ... algo entre Facebook y Twitter. Por supuesto, soy parcial con algunas de las cosas que tenemos en Photobucket, pero también odio algo de eso.

Estamos investigando en esta área nosotros mismos. No hay mucho por ahí en términos de "estándar de oro" para las referencias API de sitios web.

Las API de sitios web más comunes a las que se hace referencia son:

Otra lista aquí:

http://www.pingable.org/the-top-15-web-apis-for-your-site/

Alguien recomendó el libro Restful Web Services como una buena referencia sobre esto.

(No dude en editar la lista anterior para agregar otros sitios web de alto perfil con API)

La api de Last.fm sigue siendo una de las apis mejor conservadas de la red. También ha existido por más tiempo que la mayoría, porque comenzó básicamente como eso.

http://www.last.fm/api

Me parece que la documentación de la API es tan (o más) importante que el diseño real de la API.

La documentación bien escrita y simple compensará cualquier defecto de diseño. Eso es lo que aprendí después de ver los diversos enlaces publicados. Específicamente, la documentación de Last.fm parece muy buena: fácil de navegar y fácil de entender.

No tengo ninguna experiencia con los demás, pero a pesar de que ha evolucionado a lo largo de los años, la API de Facebook sigue siendo horrible. No se acerca a ser un "estándar de oro". Más bien, es algo que las personas luchan y aprietan los dientes porque una vez que finalmente lo hacen bien, puede agregar mucho valor.

Si estuviera diseñando una aplicación web hoy para un sitio web existente, suponiendo que el sitio web estuviera bien diseñado con respecto al uso adecuado de HTTP, usaría el sitio web existente como guía de diseño .

Tome como ejemplo, tiene todo el espacio de URI ya mapeado . Tiene un conjunto completo de interconexiones definidas entre las diferentes representaciones. Los usuarios del sitio ya están familiarizados con la estructura del sitio y, por lo tanto, la estructura API ya estaría familiarizada.

La única parte que debe cambiar es el contenido de las representaciones , para eliminar todo marcado innecesario. Sería necesario agregar algunos enlaces con plantillas adicionales para permitir búsquedas que actualmente solo son accesibles a través de JavaScript. Por ejemplo, buscar un usuario no es fácilmente detectable mediante la navegación, ya que actualmente el enlace se crea a través de javascript.

La decisión realmente difícil es qué tipo de medios usar . Puede usar bare bones html con el marcado de metadatos del estilo RDFa, o enloquecer y usar el nuevo formato de Microdata en Html5. O bien, puede devolver un tipo de medio personalizado basado en xml o Json. Algo así como application / vnd..question + xml, etc. El tipo de medio personalizado hace que el control de versiones sea realmente fácil, pero es menos accesible para los clientes que no fueron diseñados para acceder directamente a . Los tipos personalizados se podrían usar en combinación con los suministros Atom que ya están en su mayoría en ,

Diseñar una API web no es realmente diferente de diseñar un sitio web , aparte del hecho de que está entregando contenido que será consumido por un programa que no es un navegador web.

Lo que no desea hacer es crear una capa de acceso a datos basada en HTTP . Eso es como mostrar tu ropa interior al mundo. El sitio web existente está optimizado para todos los escenarios de uso común, muchos de los patrones de acceso a la API serán similares, así que reutilice las "vistas" que ya se han creado. Puede ser necesario agregar algunos enlaces adicionales aquí y allá para que sea un poco más rápido para que los programas obtengan los datos que desean, pero pueden agregarse de manera incremental a medida que surja la necesidad.

Los sitios web bien escritos ya son API muy efectivas para los clientes de los navegadores web, en realidad no es necesario volver a la mesa de diseño para admitir otro tipo de cliente. La estructura API no necesita cambiar, solo el contenido entregado.

Verificaría OpenSocial, un movimiento para crear un Estándar API para redes sociales. Usan REST para esto y tienen un enfoque centrado en el "usuario". Pero este es un enfoque muy bien documentado que podría ayudar incluso a un sitio que no está totalmente basado en lo social. Si está buscando implementaciones de código interno, observe el sistema de enganches Drupals y Wordpress.

http://code.google.com/apis/opensocial/