¿Expone el servicio web directamente a los clientes web o mantiene una delgada capa de scripts en el servidor?

Question

Estoy desarrollando un servicio web REST (Java, Jersey). La gente para la que estoy haciendo esto quiere acceder directamente al servicio web a través de Javascript. Un poco de instinto me dice que no es una buena idea, pero realmente no puedo explicar ese instinto. Mi enfoque natural hubiera sido que el servicio web hiciera la lógica real y el acceso a la base de datos, pero también tuviera una capa de scripts (relativamente delgada) del lado del servidor (por ejemplo, en PHP). Los clientes hablarían con la capa PHP, que a su vez hablaría con el servicio web. (El servicio web sería bastante local para el servidor Apache/PHP e implícitamente confiará en las llamadas desde la capa de script. La capa de script se encargaría de la administración de la sesión). (Por cierto, no estoy hablando solo de ocultar el servicio web detrás de un Apache que simplemente redirecciona las llamadas)

Pero como me encuentro a falta de palabras/argumentos para explicar mi instinto, me pregunto si mi instinto es correcto, nótese que mientras he estado desarrollando todo tipo de software en todo tipo de idiomas y marcos por 17 años, esta es la primera vez que desarrollo un servicio web.

Así que mi pregunta es básicamente: ¿cuál es su opinión? ¿Hay alguna configuración estándar? ¿Está mi instinto totalmente equivocado? ¿O parcialmente? ; P

Muchas gracias,

Max

PS: Yo podría añadir unos pocos bits de información sobre el uso previsto de toda la aplicación:

• se accederá por diferentes tipos de usuarios, parcialmente público en general, parcialmente privilegiado
• por lo tanto, todas las principales combinaciones de OS/navegador se pueden esperar como clientes
• Sin embargo, escribir el cliente no es mi responsabilidad
• tendrá potencialmente muy alta carga/tráfico
• lógica del servicio web más adelante se ampliará de forma masiva para otro producto que es básicamente un superconjunto de la funcionalidad del proyecto actual
• existe una probabilidad significativa de que en algún momento una API deba ser expuesta y pueda ser utilizada por desarrolladores de terceros; obviamente, con algunas restricciones
• en algún punto, la vista pública del producto también debería ser accesible a través de teléfonos inteligentes (en otras palabras, tal vez una versión personalizada del sitio para adaptarse a la pantalla más pequeña y diferentes métodos de entrada)

Answer 1

No creo que acceda a un servicio web REST directamente a través, p. JavaScript es generalmente una mala idea, porque para eso está diseñada la arquitectura REST para. Para su caso de uso, puede tener algunas implicaciones que considerar:

• Su servicio web tendrá que encargarse de la administración de usuarios. Como la arquitectura REST no es compatible con un estado de sesión del lado del servidor, deberá realizar la autenticación y la autorización en cada solicitud. Los usuarios deberán mantener su estado en el lado del cliente.
• La implementación de su servicio web tendrá que encargarse de problemas como el almacenamiento en caché y el equilibrio de carga y todas las demás cosas que podría haber asignado, p.PHP "proxy" guión

Para sus necesidades:

todas las combinaciones de sistema operativo/navegador puede esperarse ya que los clientes

Ya que WEBSERVICE sólo entregar los datos (por ejemplo JSON o XML) esto no debería ser un problema. La parte de JavaScript solo tiene que preocuparse de emitir las solicitudes correctas.

tendrá potencialmente muy alto carga/tráfico

Si sigue estrictamente la arquitectura REST se puede hacer uso de cachés HTTP. Pero tenga en cuenta que la naturaleza sin estado siempre causará más tráfico.

lógica del servicio web más tarde será ampliado de forma masiva para otro producto que es básicamente un superconjunto de la funcionalidad del proyecto actual

Lo bueno de los servicios web abiertos es que pueda vagamente pareja ellos juntos.

hay una probabilidad significativa de que en algún momento una API deben ser expuestos que puede ser usado por tercera parte desarrolladores -, obviamente, con algunas restricciones

vez más, con servicio web REST se ya tiene una API expuesta para desarrolladores. Es en sus clientes para decidir si esto es bueno o malo.

en algún momento, la opinión pública del producto debería ser accesibles a través de los teléfonos inteligentes

Otra ventaja para hacer su servicio web REST públicamente accesible. La mayoría de las API de teléfonos inteligentes admiten solicitudes HTTP, por lo que solo tendrá que desarrollar la GUI para la plataforma de teléfono específica que realiza llamadas directas al servicio web.

Answer 2

En primer lugar, me estoy extendiendo a lo que Daff respondió anteriormente. Estoy ampliando la respuesta de Daff desde el punto de mi aprendizaje o diseño e implementación de RESTful WebServices y tenga en cuenta que todavía estoy aprendiendo.

Cuando comencé a aprender RESTful WS con Java, Jersey (0.3 IIRC), tuve preguntas similares y la causa principal es la concepción "Total" de la RESTful Architecture. El error más "Grave" que realicé fue el uso de JAXB para XML y Jackson para la serialización JSON (de) directamente desde/hacia los beans de persistencia. Esto infringe totalmente el principio de REST y, por lo tanto, crea algunos problemas vitales en la creación de un servicio web escalable, altamente disponible y de alto rendimiento.

Mi error fue, pensando en términos de API a.k. un Servicio, cuando pensamos que RESTful WS deberíamos olvidarnos de "API" y pensar Recursos.Deberíamos tener mucho cuidado en interconectando los recursos. Mi comprensión de esto solo vino después de leer this, se lo sugiero a cualquiera que quiera crear su propio servicio web. Mi conclusión es qué es El recurso es RESTful WS/Architecture qué API para una interfaz nativa o para el servicio web SOAP. Por lo tanto, le sugiero que diseñe sus recursos con cuidado y comprenda que no hay límite en la cantidad de recursos que su servicio web puede tener.

Así que aquí viene cómo concluí en la implementación de sistemas exponiendo una "API" a través de RESTful WS. Creo una API que trata la comunicación con entidades comerciales, por ejemplo, PersistentBook, que contiene Id of PersistentAuthor o el objeto en sí. Toda la lógica de negocios considerando las entidades persistentes se encuentra en la capa de implementación API.

La capa de servicio web utiliza la capa API para realizar sus operaciones en los recursos. La capa de servicio web usa entidades persistentes para generar representaciones de beans y viceversa, la característica clave aquí sería que la representación de PersistentBook tendría un URI para PersistentAuthor. Si deseo utilizar la serialización automatizada (de), creo otra capa de dominio, p. Libro, autor, etc.

Ahora bien, como se mencionó Daff almacenamiento en caché sería inevitable, mis puntos de control para ellos son -

• Soporte para 'Cache-Control', 'Last-Modified', cabeceras de respuesta 'ETag' y Los encabezados de solicitud 'If-Modified-Since', 'If-Match-None' son la clave. Nota de mis aprendizajes más recientes: use el encabezado 'Vary' en caso de representaciones variables (negociación de contenido) basadas en el encabezado 'Aceptar'.
• Usando un caché del lado del servidor como Squid, Barniz en caso de que los clientes no usen el almacenamiento en caché. Una cosa que aprendí teniendo todo el soporte de encabezado correcto no cuenta para nada si los clientes los soportan y de hecho aumenta el costo en términos de computación y badnwidth;)
• Uso de Content-Encoding.