tutorial - Ruta correcta para verificar la existencia de recursos en una API RESTful

restful services

Question

¿Cuál es la mejor manera de diseñar un punto final de API para verificar la existencia de recursos?

Por ejemplo, hay una base de datos de usuario. Mientras el usuario nuevo intenta registrarse, quiero comprobar si el correo electrónico se ha usado sobre la marcha.

Mi idea es: POST /user/exists y la carga útil sería algo así como {"email": "[email protected]"} . La respuesta sería 200 OK o 409 Conflicto.

¿Es esta una forma adecuada?

¡Gracias!

Answer 1

Creo que la forma correcta de verificar la existencia es usar un verbo HEAD para cualquier recurso que normalmente obtendría con una solicitud GET .

Hace poco me encontré con una situación en la que quería comprobar la existencia de un archivo de video potencialmente grande en el servidor. No quería que el servidor intentara comenzar a transmitir los bytes a ningún cliente, así que implementé una respuesta HEAD que solo devolvía los encabezados que el cliente recibiría al realizar una solicitud GET para ese video.

Puede consultar la especificación W3 here o leer esta publicación del blog sobre usos prácticos del verbo HEAD .

Creo que esto es impresionante porque no tiene que pensar en cómo configurar su ruta de manera diferente a una ruta REST completa para verificar la existencia de cualquier recurso, ya sea un archivo o un recurso típico, como un usuario o alguna cosa.

Answer 2

Yo prefiero:

HEAD /users/email/[email protected]

Explicación: está intentando encontrar a través de todos los usuarios a alguien que esté utilizando el correo electrónico [email protected] . Supongo que aquí el correo electrónico no es la clave de su recurso y que tiene cierta flexibilidad, porque si necesita otro punto final para verificar la disponibilidad de otra información del usuario, este enfoque puede encajar muy bien.

Como respuesta, solo devuelve 200 (si no está disponible) o 404 (si está disponible) como respuesta de código http.

También puedes usar:

HEAD /emails/[email protected]

si HEAD /users/email/[email protected] entra en conflicto con un recurso de descanso existente, como GET /users/email/[email protected] con una regla de negocios diferente. Como se describe en la documentación de Mozilla :

El método HEAD solicita una respuesta idéntica a la de una solicitud GET, pero sin el cuerpo de respuesta. *.

Por lo tanto, tener un GET y una HEAD con reglas diferentes no es bueno.

Una HEAD /users/[email protected] es una buena opción si el correo electrónico es la "clave" de los users , porque (probablemente) tiene un GET /users/[email protected] .

Answer 3

HEAD es el más eficiente para los controles de existencia:

HEAD /users/{username}

Solicite la ruta de un usuario y devuelva un 200 si existe o un 404 si no existe.

Tenga en cuenta que probablemente no desee exponer puntos finales que verifican las direcciones de correo electrónico. Se abre un agujero de seguridad y privacidad. Los nombres de usuario que ya se muestran públicamente en un sitio, como en reddit, podrían estar bien.

Answer 4

GET /[email protected]

Esta es una consulta de búsqueda básica: encuentre los usuarios que tienen la dirección de correo electrónico especificada. Responda con una colección vacía si no existe ningún usuario, o responda con los usuarios que cumplan la condición.