Elija entre http 401 y 409 [duplicar]

12

Tengo dos API para seguir & dejar de seguir a un usuario.

domain/uid/follow    (http POST)       to follow user
domain/uid/follow    (http DELETE)     to unfollow user

Sigue al usuario y responde con el código http 200. Cuando el usuario intenta seguir de nuevo (usuario ya seguido) respondo con 401.

Preguntas :

1: ¿Debo responder con 401 no autorizado o 409 en conflicto?

2: igual para cuando el usuario no está siguiendo a alguien e intenta dejar de seguirlo.

Editar:

No estoy usando una sola API para cambiar el comportamiento de follow/unfollow . Tengo 2 API separadas para ambas acciones.

No tengo ninguna razón particular para responder con un error. El único lugar en el que se utiliza son las pruebas automatizadas de las API para verificar que un usuario no se sigue dos veces.

    
pregunta Shaharyar 21.07.2017 - 12:59

3 respuestas

42

Técnicamente, depende del método HTTP que uses. Le sugiero que use PUT porque, si lo hace, esta línea de argumento funciona bien:

Si alguien quiere seguir a otro usuario y ya lo hace, eso está completamente bien, ¿no es así? Lo mismo vale para dejar de seguir. Así que siempre devuelve 200 .

Ese comportamiento se llama idempotencia. Consulte esta explicación para obtener más información.

Si va a POST, técnicamente debería crear un recurso según las convenciones de HTTP. Crear un recurso no es idempotente, por lo que su interfaz tampoco podría serlo. Si sigue esa convención, debe devolver el estado 409 Conflicto o 422 Entidad no procesable en solicitudes de doble seguimiento y no seguimiento. Indicar la razón con más detalle en un cuerpo de respuesta de error es una buena práctica; ayuda mucho a tus consumidores de API.

Sin embargo, RFC 7231 (HTTP 1.1) no requiere que siempre cree un recurso; Por lo tanto, un POST idempotente también es una solución válida.

Nota: 401 significa Unauthorized . Eso significa que la solicitud no proporciona credenciales o las credenciales proporcionadas son no válidas . Sin embargo, asumo que usted validó exitosamente las credenciales antes de intentar hacer el seguimiento / dejar de seguir. Por lo tanto, responder con 401 no tiene absolutamente ningún sentido en esa situación. 403 Forbidden es descabellado y no es muy aplicable (pero aún es mejor que 401).

    
respondido por el marstato 21.07.2017 - 13:02
18

No convierta errores de negocios en códigos de estado HTTP. Los códigos de estado deben interpretarse por el cliente HTTP, no por su dominio o por el propio usuario. Si desea comunicar un mensaje al usuario, hágalo en el cuerpo de la respuesta

Creando el seguimiento 1

POST /domain/uid/follow HTTP/1.1
...
HTTP/1.1 201 Created
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Location: /domain/uid/follow/123456

Duplicar el seguimiento 2

POST /domain/uid/follow HTTP/1.1
...
HTTP/1.1 409 Conflict
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 100
{"message":"you are already following Shaharyar!"}

Para obtener más información sobre la causa del error, podemos usar encabezados personalizados.

MyApplication-error: AlreadyFollowingUserError

Dejar de seguir

  

2: igual para cuando el usuario no está siguiendo a alguien e intenta   dejar de seguirlo.

Este segundo caso es ligeramente diferente. Si estamos intentando eliminar un recurso que no existe

DELETE /domain/uid/follow HTTP/1.1
...
HTTP/1.1 404 Not Found
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 1000
MyApplication-error: ResourceNotFound
{"message":"resource not found"}

Por otro lado, como @K. Alan Bates, como comentó (gracias Alan), podríamos hacer que la operación sea idempotente, tan pronto como el URI que solicitamos esté todavía disponible.

DELETE /domain/uid/follow HTTP/1.1
...
HTTP/1.1 204 No content
Date: Fri, 20 Dec 2017 14:30:00 GMT
Content-Type: application/json
Content-Length: 100

He elegido 204 por simplicidad. Puede ser 200 o 202.

En cualquier caso, no deberíamos responder con 401 Unauthorized a menos que el servicio de seguridad indique lo contrario.

1: Editar: idealmente después de la creación de un nuevo recurso, deberíamos responder con la nueva ubicación del recurso y el código de estado 201

2: Editar: el código de estado aquí dependerá del método. Si enviamos un POST está solicitando un nuevo recurso. Si ya existe, 409 Conflicto está bien. Si la solicitud crea un nuevo recurso, 201. Si enviamos un PUT, 200 o 204 están bien

    
respondido por el Laiv 21.07.2017 - 14:32
2

Basado en el RFC mencionado en el comentario de Willem Renzema sobre la respuesta de marstato, creo el enfoque más limpio es hacer que su POST cree un nuevo recurso. Supongo que podrías hacer algo simple como "domain / uid / following" si no quieres tener que buscarlos en tu cliente. Luego, cuando quieres dejar de seguir, borras ese recurso. Si llega otra publicación para el siguiente URI cuando ya existe, devuelve 303 y devuelve el encabezado "Ubicación de contenido" con el recurso 'siguiente'.

Una ventaja adicional de crear los recursos 'siguientes' es que puedes usar eso para crear una lista de lo que un usuario está siguiendo.

    
respondido por el JimmyJames 21.07.2017 - 19:06

Lea otras preguntas en las etiquetas