2012-03-23 11 views
6

Tengo curiosidad por cómo soluciono el problema de concurrencia para una API RESTful. Más específicamente, tengo una colección de objetos que necesitan un examen y actualización manual, p. un número de filas que necesitan una columna actualizada a mano; sin embargo, si abro la API a una cantidad de clientes, todos los agarrarán de arriba hacia abajo, de modo que muchos usuarios llenarán la columna de la misma fila al mismo tiempo. Prefiero no tener colisiones, y la forma simple y con estado es simplemente volcar elementos en una cola en el servicio y abrirlos cuando la gente los solicite.Las API RESTful deben ser apátridas, pero ¿qué ocurre con la simultaneidad?

¿Cuál es la versión sin estado de esto? Hash por dirección IP, o al azar agarrar filas basadas en id?

:: Actualización ::

"Gestión de recursos humanos, por lo que debe ser simplemente sin estado desde el punto de vista del cliente?

Eso sin duda tiene mucho sentido. Estaba leyendo un artículo (ibm.com/developerworks/webservices/library/ws-restful) acerca de las API RESTful, y después de encontrar el bit sobre la búsqueda, me preocupaba que mi cola bastante estable fuera similar a la de una página, pero en realidad son bastante diferentes. "página siguiente" es relativa en el lado del cliente, mientras que "pop" es siempre sin estado para el cliente: no importa lo que apareció antes.

¡Gracias por aclarar mi mente! -Me

+0

Realmente no veo el problema/pregunta aquí. Las API RESTful pueden (y casi siempre son IME) respaldarse con servidores con estado. ¿Podrías aclarar el problema que intentas resolver? –

+0

Las etiquetas electrónicas se pueden utilizar para proporcionar simultaneidad –

+0

Hrm, por lo que simplemente debe ser apátrida desde la perspectiva del cliente. Eso ciertamente tiene mucho sentido. Estaba leyendo un artículo (https://www.ibm.com/developerworks/webservices/library/ws-restful/) sobre las API RESTful, y después de encontrar el bit sobre la búsqueda, me preocupaba que mi cola bastante declarada fuera similar. para incrementar por una página, pero en realidad son bastante diferentes ya que "página siguiente" es relativa en el lado del cliente, mientras que "pop" siempre es sin estado para el cliente. No importa lo que apareció antes. Gracias por aclarar mi cabeza! –

Respuesta

3

Hay dos enfoques básicos que puede tomar:

  1. ir completamente sin estado, y adoptar una estrategia de "solicitud de último gana". Por extraño que parezca, es probable que sea la solución más limpia en términos de previsibilidad, escalabilidad, complejidad del código e implementación tanto en el lado del cliente como del servidor. También hay un montón de precedencia para ella: mira cómo los sitios como Google paginar consultas utilizando un start=10 de la página 2, start=20 de la página 3, etc.

    Usted puede encontrar que los cambios de contenido dentro de las páginas a medida que navega de ida y vuelta entre ellos, pero ¿y qué? Siempre obtienes la información más reciente y Google puede manejar tus solicitudes en cualquiera de sus muchos servidores sin tener que encontrar tu información de sesión para determinar cuál fue tu último contexto de consulta.

    La mayor ventaja de este enfoque es la simplicidad de la implementación de su servidor. Cada solicitud puede pasar directamente a la capa de datos en el back-end, y está absolutamente lista para el almacenamiento en caché a nivel HTTP (a través de E-Tags o cabeceras Last-Modified) y del lado del servidor (usando algo como Memcache, para ejemplo).

  2. Vaya a la búsqueda de una forma de que sus servidores distribuyan algún tipo de bloqueo o token por cliente para cada "sesión" de API. Esto será como tratar de luchar contra la marea del océano con un palo, porque terminará fracasando y frustrado.

    ¿Cómo identificará a los clientes? ¿Claves de sesión? ¿Dirección IP? Descriptor de archivo para el socket que montaron (buena suerte con eso si está usando un transporte como HTTP donde la conexión se puede cerrar entre solicitudes ...)? Los detalles que elijas para esto tendrán que persistir en el lado del servidor, o tendrás que usar alguna característica desagradable de sesión adhesiva en tu servidor de aplicaciones (y si es así, cielos ayude a tu cliente si el servidor que está utilizando deja de funcionar) media sesión).

    ¿Cómo manejará los clientes API que desaparecen despiadadamente?¿Excederá el tiempo de espera de sus bloqueos de sesión haciendo que un hilo de reaper limpie los inactivos? Eso es más código, más complejidad y más lugares para ocultar errores. ¿Qué pasa con los clientes de la API que vuelven de un largo tiempo de inactividad y tratan de reutilizar un bloqueo caducado, cómo deberían construirse aplicaciones cliente para manejar esa situación?

Podría seguir, pero espero que pueda ver mi punto. Vaya con la opción 1 y vaya sin estado. De lo contrario, terminarás tratando de rastrear el estado del cliente en el lado del servidor. Y lo único que debe hacer un seguimiento del estado de un cliente es el cliente mismo.

+0

No creo que la aceptación de los cambios de contenido al navegar en las páginas de conjunto de resultados sea la única forma de pensar. Puede ver entradas dobles - OK (y el cliente puede manejar esto de todos modos), pero también puede perder entradas totalmente debido a las eliminaciones en el alcance de las páginas pasadas/anteriores - no es agradable. Para los resultados de búsqueda de Google que pueden no importar, pero en otros contextos puede. –

+0

Como alternativa, puede buscar "todos los ID" en el cliente (OK, para los resultados de búsqueda de Google que no es factible la mayoría del tiempo) y recorrer esta lista página por página, cargando más contenido al llegar a la página del conjunto de resultados con ese ID subconjunto. Las malas noticias son que el problema vuelve justo a la vuelta de la esquina: puede haber elementos mientras tanto eliminados (que no pueden cargarse más, deben ser atrapados de alguna manera), y puede haber nuevos elementos agregados mientras tanto no se ve por navegando por su conjunto de resultados actual. Por lo tanto, la pregunta es: ¿qué es más importante para ti? –

+0

Si no le importan los elementos faltantes o dobles mientras navega por el conjunto de resultados página por página, entonces estará bien si pone el número de página o el rango de índice en la URL como parámetro, cargando el servicio con la carga y tirar todos los artículos que se habrían colocado en cualquier página antes. (¿Cómo maneja Google esto? ¿Alguien intentó una consulta absurda e inicialmente especificó un número de página alto, como "query = millionaire & page = 59786"?) –

1

Está bien mantener el estado de los recursos. La "prohibición sin estado" solo se refiere al estado de la sesión.

He aquí un extracto de Roy Fielding's seminal REST derivation:

A continuación añadimos una restricción a la interacción cliente-servidor: comunicación debe ser sin estado en la naturaleza, como en el estilo cliente sin estado-servidor (CSS) de Sección 3.4.3 (Figura 5-3), , de modo que cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender la solicitud, y no puede aprovechar ventaja de cualquier contexto almacenado en el servidor. El estado de la sesión es por lo tanto, se mantiene completamente en el cliente.

Cuestiones relacionadas