¿Devuelve verdadero/falso en el servicio REST?

Estoy diseñando un servicio REST y hay una necesidad de una verificación para ver si una dirección se ingresó correctamente. Lo que estoy pensando es cómo diseñaría una interfaz REST para verificar si una dirección completa es válida.¿Devuelve verdadero/falso en el servicio REST?

Tengo este/servicio de dirección y podría, por ejemplo, hacer un POST /address/validation que devuelva un xml/json verdadero o falso, pero me parece bastante desatinado.

Otra forma sería hacer un GET /address?street=xxx&nr=xxx&zipcode=xxx (y algunos parámetros más) y devolver un 200 OK si es correcto o un 404 No encontrado si no es correcto, ¿qué puede ser más REST-ful?

empecé opción 1), pero más me lo estoy pensando hacer, opción 2) con el GET se siente mejor ...

ideas?

Fuente

2011-04-28 Johan Danforth

Desde una perspectiva RESTful, realmente está devolviendo un recurso nuevo, llámelo AddressValidation, que contendrá su valor verdadero o falso. Entonces, un enfoque sería hacer un POST al /addressvalidation?street=xxx etc. Estaría bien devolver el resultado como JSON o usar códigos de estado. Aunque no estoy seguro de que 404 sea apropiado; es posible que desee mirar this discussion of validation return status codes.

Tengo el mismo problema con el enfoque GET /address?street=xxx&nr=xxx&zipcode=xxx como usted lo propone. Para mí, si devuelve 404, eso significa que la dirección literalmente no se encuentra (es decir, no existe en la base de datos), en lugar de que no sea válida (por ejemplo, el código postal es un formato no válido; no puede haber ninguna dirección de ese tipo)) Nuevamente, vea la discusión vinculada; parece que 400 es una respuesta más apropiada.

Fuente

2011-04-28 14:47:18

Gracias Jacob. De hecho, vamos a probar 2 cosas aquí, tanto si la dirección está en el formato correcto, y luego verificamos si la dirección existe realmente. Estos son, como usted dice, dos cosas diferentes y deben devolver diferentes códigos/datos. –

-2

Siento que hacer POST y devolver códigos de estado (200 OK si es correcto o 404 no encontrado si no es correcto) es más tranquilo. Porque no estás OBTENIENDO algo, GET no se ve apropiado. Está PUBLICANDO cierta información al servidor y procesa algo (validación) y devuelve alguna respuesta.

Fuente

2011-04-28 14:41:43 Reddy

POST no se ve nada bueno para esto si me preguntas. El RFC establece que "El método POST se usa para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el URI de solicitud en la línea de solicitud" – bluehallu

Obtener es mejor que el POST en este caso , porque la operación es idempotente –

¿Qué tal?

GET /addressValidity?street=xxx&nr=xxx&zipcode=xxx 
=> 
200 OK 
Content-Type: text/plain 

true

Fuente

2011-04-28 15:19:00

Gracias Darrel, es simple y me gusta. Sin embargo, queda fuera de nuestro comportamiento normal de siempre devolver xml o json depediendo en aceptar-encabezados. –

@Johan Obviamente, puede usar cualquier tipo de medio que desee. Text/plain es simplemente bueno para devolver valores escalares simples. Es desafortunado que la obsesión actual por "xml o json" realmente pierda algunos de los beneficios que trae REST con la capacidad de utilizar muchos tipos de medios diferentes. –

Puede devolver un objeto, como '{" result ": true}' –

¿Devuelve verdadero/falso en el servicio REST?

Respuesta

Cuestiones relacionadas