REST-¿Cómo diseñar un URI con claves compuestas?
composite-key (1)
No hay nada de malo en
PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
Los parámetros de consulta también forman parte de la identificación de recursos.
Los parámetros de ruta son útiles para definir recursos que encajan bien en una jerarquía. En su caso, el recurso no encaja bien en una jerarquía, así que no intente comprimir los parámetros en segmentos de ruta.
El único reto es qué hacer cuando el cliente reorganiza el orden de los parámetros de consulta. ¿Lo tratas como el mismo recurso, o 404? Si no está guardando en caché las respuestas GET, entonces probablemente no importa.
Si le proporcionó a su cliente una plantilla de URI para que ellos la completen, hay menos posibilidades de que le den los parámetros en el orden incorrecto.
La otra opción, si sigue su sugerencia original, es que su GET devuelva un redireccionamiento y un encabezado de ubicación a un URI con el ID de carga. p.ej
GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
=>
302 See Other
Location: freight/1232321322
Al hacer esto, su cliente no tiene que saber nada sobre el ID de carga, solo puede tomar el encabezado de la ubicación y seguir la redirección para hacer un GET, o hacer un PUT directamente contra cualquier URI que se encuentre en el encabezado de la ubicación. Esto significa que si decide que no le gusta exponer la ID en el futuro, puede cambiar el URI sin interrumpir a ningún cliente.
Tengo una pregunta sobre cómo diseñar un URI de recurso con claves compuestas.
Tengo un recurso llamado flete que tiene 4 claves / identificaciones: ID de socio, código postal inicial, código postal final y peso.
En realidad, mi recurso fue diseñado para tener una ID incremental generada por la base de datos, pero este enfoque no es tan bueno para los consumidores de API, por ejemplo, si un consumidor / socio necesita actualizar la información de carga que tiene que hacer:
GET freight? InitialZipcode = {VALUE} & finalZipcode = {VALUE} & weight = {VALUE}
La respuesta de la operación anterior sería el ID de flete, para que finalmente puedan actualizar la información:
PUT flete / {ID}
El ID de socio está implícito por el mecanismo de autenticación.
Para mí, parece extraño forzar a los socios a obtener la identificación del flete antes de actualizar la información.
Entonces mi pregunta es: ¿cómo puedo diseñar este URI?
PUT freight / initialZipcode / {VALUE} / finalZipCode / {VALUE} / weight / {VALUE}
¿Tengo que considerar el diseño de arriba?
Otra pregunta: ¿es una buena práctica incrustar partnerId en el mecanismo de autenticación? Conozco los pros (fáciles para los consumidores) y los contras (caché, imposibilidad de compartir una URI, etc.), pero no sé si en general es una buena o una mala práctica.
¡Gracias!