ebay como interfaz API para un portal web

Question

Hemos desarrollado un portal web B2B para trabajo gráfico de trabajo que es similar a Camera Ready Art (www.camerareadyart.com). Está dirigido a personas que desean convertir mapas de bits en gráficos vectoriales, diseño de logotipos y procesamiento general de imágenes, como colorear imágenes en blanco y negro a color, etc.

Queremos agregar servicios para que las personas (nuestros clientes) puedan usar un conjunto de API que proporcionamos para publicar su trabajo directamente desde su sitio sin tener que visitar nuestro sitio literalmente para publicar su trabajo.

Nunca he hecho algo así hasta la fecha, así que no tengo ideas sobre cómo puedo implementar algo como esto. También quiero saber cómo podemos implementar la seguridad para que solo aquellos que estén autorizados puedan publicar su trabajo.

¿Alguien puede darme ideas sobre cómo podemos hacer algo como esto?

Answer 1

Esta pregunta cubre un área muy grande y dudo que una sola respuesta pueda cubrir asuntos en detalle. Lo que puedo hacer es ofrecer algunos puntos de partida basados ??en los errores que he cometido.

Construir sobre su propia API
No agregue funciones de API a un sistema existente. Al hacerlo:

• conduce a una carga de prueba adicional (tendrá que probar tanto su aplicación como la API de forma independiente)
• resulta en un aumento en los costos generales de mantenimiento
• da como resultado una API de peor calidad que la que desea ofrecer

Su objetivo general debe ser construir primero la API y luego construir su aplicación sobre su propia API. Hacerlo tiene los siguientes beneficios:

• las pruebas de la API se realizan inherentemente mientras se prueba su aplicación
• no 'olvidará' agregar ningún método API requerido

Su aplicación y la lógica de su aplicación (la API) estarán separadas lógicamente; habrá una separación clara entre ellas en términos de lo que hace cada lado de la ecuación y de qué es responsable. Esto ayudará a guiar el desarrollo. Esto también le permitirá colocar muy fácilmente la aplicación y la API en diferentes máquinas cuando sea necesario.

Usar tu propia API es un punto muy importante. El diseño de su API inicialmente será subóptimo y solo al usarlo usted mismo podrá hacer que ofrezca a las personas las características que realmente se necesitan de una manera eficiente.

Terminarás con un sistema que se ve más o menos así:

-------------                          -------------
|           |                          |           |
| Your APP  | <= HTTP communication => | Your API  |
|           |                          |           |
-------------                          -------------

Esto resalta algunos beneficios adicionales: puede reemplazar 'Su APLICACIÓN' con cualquier otra aplicación, lo que permite a sus clientes crear aplicaciones para manejar las cosas de la manera que mejor funcione con ellas. También puede crear nuevas versiones de su aplicación sobre la API existente; puede ser mucho más fácil pasar a una nueva versión de su sitio web público.

Diseño de sus URL: asignación a clases y métodos
Elegir URL sensibles es un problema tan grande como elegir nombres de clase y método razonables. Derivar URL de las clases y sus métodos es un buen enfoque. Si no hay una correlación sensata entre las URL y las clases / métodos, encontrará cosas más difíciles de mantener a largo plazo.

Personalmente prefiero asociar URL a clases y métodos de las siguientes maneras:

• asignar clases a directorios de nivel superior
• métodos de asignación a subdirectorios de los directorios de nivel superior

Ejemplo:
La URL de su API es https://api.camerareadyart.com .
Tiene un objeto image con los métodos toColour () y toBlackAndWhite () .

Esto puede asignar a:

https://api.camerareadyart.com/image/toColour/
https://api.camerareadyart.com/image/toBlackAndWhite/

De manera similar para la conversión de mapa de bits a vector:

https://api.camerareadyart.com/bitmap/toVector/

Diseño de respuestas
Cuando alguien OBTIENE datos de, o PUBLICA datos a, una de sus URL, ¿qué sucede? ¿Cómo se manejan los errores, cómo se tratan las excepciones? ¿Qué forma toman las respuestas?

No puedo decirte qué hacer aquí. Personalmente, prefiero asignar las cosas lo más cerca posible de HTTP y luego ir más allá cuando sea necesario.

Por ejemplo, si se acepta una solicitud entrante y se procesa pero se encuentra con un error interno, emitiría una respuesta de estado 500. Del mismo modo, si un método API determinado requiere autenticación que no se ha proporcionado, podría emitir un 403. Aprovechar las características HTTP existentes evita que tenga que reinventar ciertas cosas.

Usar aspectos existentes de HTTP
Además de utilizar los códigos de estado HTTP de manera sensata, asegúrese de buscar un método solo HTTP para hacer algo antes de lanzar su propia solución.

¿Desea que el usuario especifique si el formato de respuesta debe ser XML o JSON? Use el encabezado HTTP Accept.

¿Desea redirigir un cliente a una URL diferente para obtener el resultado de una solicitud? Utilice el encabezado de ubicación HTTP.

Answer 2

Obviamente necesita tener sus servicios web backend diseñados y funcionando. Sin embargo, todas las características adicionales (seguridad, limitación, administración de claves OAuth, portal de suscriptores, consola interactiva para probar las API, etc.) son un conjunto bastante estándar de características que probablemente no debería desarrollar usted mismo.

Existen soluciones comerciales de API Management en el mercado. Trabajo para WSO2, que tiene un Administrador de API WSO2 100% de código abierto (Licencia de Apache), que puede descargar gratuitamente aquí o úselo como una versión alojada en la nube en WSO2 API Cloud .