mejor práctica para RESTO booleano resultados

que tienen un recursomejor práctica para RESTO booleano resultados

/system/resource

y deseo pedir al sistema booleano una pregunta acerca del recurso que no puede ser respondida por el procesamiento en el cliente (es decir, que pueden' t solo OBTENGA el recurso y mire a través de los datos reales del recurso; requiere algún procesamiento en el backend utilizando datos no disponibles para el cliente). por ejemplo

/system/resource/related/otherresourcename

Quiero que esto sea verdadero o falso. ¿Alguien tiene algún ejemplos de mejores prácticas para este tipo de interacción?

posibilidades que vienen a la mente:

uso de código de estado HTTP, el cuerpo sin devolución (huele mal)
retorno cadena de texto sin formato (verdadero, falso, 1, 0) - valores de cadena No estoy seguro lo son apropiadas para usar, y además esto parece estar ignorando el tipo Aceptar medios y siempre volviendo texto plano
proponga un objeto booleano para cada uno de mis tipos de soporte técnico y devuelva el tipo apropiado (un documento JSON con un resultado booleano único , un documento XML con un único campo booleano). Sin embargo, esto parece difícil de manejar.

Yo particularmente no quiero entrar en una larga discusión sobre el verdadero significado de un sistema REST etc - He utilizado la palabra descanso en el título porque mejor expresa el sabor general del sistema de I estoy diseñando (incluso si tal vez I estoy tendiendo más hacia RPC en la web en lugar de verdadero RESTO). Sin embargo, si alguien tiene alguna idea sobre cómo un verdadero sistema RESTful puede evitar este problema por completo, me gustaría escucharlos.

Fuente

2010-05-28 Andrew Patterson

¿Puede por favor hacer que las etiquetas sean menos confusas y más específicas? – WhirlWind

Sí, lo siento, no sabía realmente con qué etiquetar la pregunta. Lo estoy haciendo específicamente con MVC.NET, ¿pero la pregunta seguramente es aplicable a cualquier sistema REST? –

Creo que devolver texto/normal sería la opción más limpia. En lo que respecta al encabezado de aceptación, si el cliente realmente no puede manejar el texto sin formato, entonces puede volver a Json o Xml.
Personalmente, usaría las cadenas "verdadero" y "falso". La mayoría de los lenguajes de cliente pueden analizar esas cadenas a su valor apropiado.

Fuente

2010-05-28 02:18:19

Acepto que es poco probable que no puedan manejar el plan de texto, pero en el resto de la API pueden usar el único tipo de Aceptar que quieran, es decir, en muchas de mis pruebas utilizo el cliente de reposo y simplemente configuro Aceptar aplicación/json. En ese caso, realmente tengo que devolver el JSON booleano envuelto ¿no? –

Sí, según 'http: // tools.ietf.org/html/rfc2616 # section-14.1' si su cliente no dice que admite texto/plain, entonces no debería enviarlo. –

hmm, difícil de responder (su ejemplo es demasiado abstracto para mí).

Generalmente puede diseñar una información booleana como la información de recursos o como un recurso dedicado. Ejemplo para el dominio de pedidos, cuando desea saber si el pedido está completo o no (pregunta booleana).Cuidado con este ejemplo se simplifica (mundo de pedidos mucho más compleja;)

Diseño estado de orden como carga útil de datos

llamada HTTP: HTTP GET /orders

le daría 200 espalda bien con la carga útil (formato JSON): { id : "1" , completed : "true" }

Diseño estado de orden como recurso

llamada

HTTP: HTTP GET or HEAD /orders/completed/1

ahora para obtener su respuesta "booleano" se puede comprobar si el estado de respuesta HTTP era 404 o 200. 400 diría que la orden no se ha completado todavía, 200 diría que se complete.

Para ayudarlo más tiene que ser más específico, ¿cuál es en detalle su "pregunta booleana"? ¿Cuál es el recurso real y el recurso relacionado?

Fuente

2010-05-30 10:02:57

Manuel, gracias por sus comentarios reflexivos. Imagine que tenemos un recurso 'john', y otro recurso 'bob'. Ambos tienen propiedades como el nombre, la dirección, la fecha de nacimiento, la lista de amigos, etc. Por lo tanto, ambos son de "recursos" y se pueden obtener con un GET en una arquitectura tranquila. Sin embargo, quiero hacer una pregunta booleana sobre la relación entre estos dos recursos. La relación real es simple (es decir, puedo llegar a una persona a través de amigos de la otra persona), pero obviamente implica algún cálculo en el extremo del servidor. Así que quiero preguntar HTTP GET/bob/isrelated/john –

Puedo pensar en dos posibilidades: 1) Haz un GET en/bob/friends y comprueba si john es un elemento dentro de la respuesta. O vaya un paso más allá y haga GET/bob/friends/john, si obtiene un 404, entonces no hay amistad entre ellos, de lo contrario 200. 2) Incluya esta información directamente en el recurso: GET/bob, luego busque dentro de bob john .... Si John es parte de la respuesta, hay una relación, de lo contrario. Desde la perspectiva de Rest, no pensaría directamente en términos de computación del servidor (es el detalle de la implementación de la API). –

Sí, estoy de acuerdo en que si mis 'relaciones' fueran expresables, simplemente las incluiría en el recurso. Lo que quiero decir con respecto a la computación en el servidor es que un recurso puede tener cientos de miles de recursos relacionados (es el cierre transitivo completo de una red compleja). Entonces, si la relación existe depende de datos que no se pueden enviar al cliente, debe ser computada por el servidor –

mejor práctica para RESTO booleano resultados

Respuesta

Cuestiones relacionadas