¿Cuáles son algunas de las trampas/consejos que se pueden dar para desarrollar un servicio web

Question

Buscando desarrollar un servicio web (api) en PHP para ofrecer a los clientes una manera más fácil de integrarse con nuestra plataforma. Hay llamadas de flujo de trabajo que se validarán con user/pass, así como algunas opciones de informes.

Lo siento, no puedo publicar más detalles o códigos sobre el tema y nunca he desarrollado un servicio web, pero he tenido experiencia en su uso a través de SOAP.

Ahora también tendría que ofrecer un estado o estado del flujo de trabajo y creo que REST sería la mejor opción aquí, pero aún estoy buscando opiniones al respecto.

Para informar ¿Me gustaría ofrecer diferentes opciones como XML, Excel/CSV por alguna razón que elegiría una sobre la otra?

¿Cuáles son algunos de los escollos que debería buscar?

¿Cuáles son algunas gemas que cualquiera podría ofrecer?

Gracias de antemano por cualquier ayuda, ya que esto es muy importante para mí.

ACTUALIZACIÓN # 1:

• ¿Cuál sería el método más seguro?
• ¿Cuál es el método más flexible (Independiente de la plataforma)

ACTUALIZACIÓN # 2: un poco sobre el flujo de datos. Cada usuario tiene creds para usar la API y no se comparten datos entre los usuarios. El uso es enviar una solicitud, la solicitud se procesa y se entrega una devolución. sin actualizaciones. (Creo que Google) se realiza una búsqueda y se dan resultados, pero en mi caso solo se da un resultado. No sé si esto es necesario, así que es un FYI.

Answer 1

Always handle errors and exceptions. 

Los problemas siempre harán sentir su presencia en la aplicación/api. Ya sea al inicio o a través de un mayor desarrollo. No deje esto como una tarea final, y deje en claro cuándo ocurre un error, con mensajes de respuesta bien documentados.

Además, si su servicio manejará muchas solicitudes, y para el mismo ID de recurso (independiente del usuario) se devuelve el mismo recurso, asegúrese de almacenar en caché la información. Y esto no solo por razones de rendimiento, sino también por los casos en que los errores se pusieron de punta. De esta forma, al menos puede servirle algo al cliente (posiblemente sea útil, se requiere más contexto para ser explícito).

Answer 2

El elemento más grande y más importante que puedo ofrecer es garantizar su infraestructura detrás de la WS o al menos lo que está sirviendo a través de la WS es apátrida. En el momento en que te desvíes de esto, se convertirá en una pesadilla y comenzarás a tener que calzar el código para evitar que tus datos se ensucien.

Un ejemplo serían dos clientes que realizan cambios en los datos a través de WS, es decir ... guardan la configuración. Cómo lidiar con eso al final hace las cosas interesantes. Si sus datos solo se dirigen hacia el exterior, entonces se encuentra en una situación mucho mejor si tiene que admitir el envío de datos al back-end.

Además, piense en la API en profundidad como con cualquier API pública. En el momento en que tenga una versión en libertad y luego decida que las necesidades de la API han cambiado o se han depreciado, comenzará a causar problemas para la base de clientes que utiliza su WS.

Answer 3

Actualmente estoy trabajando en una aplicación web que incluye un servicio web (o 2 en ASP.NET MVC) y recomiendo mirar los principios detrás de la Arquitectura Orientada a Servicios (SOA) ya que lo que he encontrado es que aspecto importante es corregir el diseño de la API del servicio web, ya que afectará al resto de su back-end y le facilitará la vida o le hará tropezar con las paredes debido a la frustración.

Fundamentalmente SOA significa diseñar el servicio web en torno a los procesos de negocio, es decir, cómo las personas que usan su API pueden usarlo.

Un buen diseño es siempre una buena idea, por lo que le recomiendo que lea un montón sobre los principios de diseño de servicios web antes de comenzar a codificar y ahorrarse u otro desafortunado trozo de dolor más tarde.

También asegúrese de que su diseño sea ágil ya que cambiará con frecuencia a medida que se produzca la comunicación entre su empresa y sus clientes.

Answer 4

Un poco más relacionado con la implementación que con el diseño: Yo decidiría que la salida del servicio sea XML, esto puede ser muy fácil de analizar, por todos los idiomas decentes. Además, si algún cliente necesita otro resultado, puede transformar esos XML a través de algunos procesadores XSLT y ofrecer "otros" servicios web, que generan JSON o cualquier otra cosa que necesiten. En cuanto a los informes, eso depende de cómo se usarán los informes, si los clientes los procesan y solo necesitan los datos de los informes, entonces sugiéranle XML. En mi opinión, trabajar con CSV es más difícil porque hay que tener en cuenta todo tipo de casos especiales como "qué pasa si mis datos contienen el campo separador", "el cliente podrá especificar el separador", "cómo lo representaré". datos anidados ", o todos estos son simples con XML. Si su cliente necesita informes para usarlos de fábrica, puede usar BIRT -beautiful and free

Answer 5

Ofrecer múltiples salidas como JSON, CSV, YAML o XML es bueno, eso le da al usuario final la comodidad, a un muy pequeño ¡costo! El volcado de datos siempre es más fácil que el procesamiento, y dicen que ya analizan JSON por algún motivo; es mucho más fácil conectarlo para su API que implementarlo, digamos un analizador XML. Actualmente veo analizadores de XML en todas partes, por lo que probablemente no debería ser un problema, pero me gusta la naturaleza más "aireactiva" de JSON; He mirado un poco en YAML pero nunca lo he usado, pero parece prometedor, definitivamente lo usaré para los archivos de configuración de mi próximo proyecto.

En el lado de la seguridad de cualquier cosa que procesa dinámicamente cualquier entrada que el usuario da, uno debe tratar dicha entrada como algo que no pincharías incluso con un palo.

IMHO stateless REST es mejor que SOAP porque es menos sobrecarga, uno puede comunicarse fácilmente con un REST-api a mano usando curl o wget desde el terminal. Jump-start, por así decirlo.

Lo recomendaría a tomar una respiración profunda, un lápiz & un papel, sentarse y esbozar todo lo que va a ser necesario. Luego eliminas las cosas menos importantes y tomas un nuevo documento y comienzas a organizarlo. Puede agregar las cosas menos importantes en la próxima versión de la API.

Trate de diseñar la API para que no se encerre en una esquina, no haga suposiciones sobre hacia dónde se dirigirá después.