Representar acciones (verbos) en REST URI

14

Tengo que realizar una operación de impresión para los documentos de mis clientes. Necesito que las otras operaciones estándar se realicen también, como agregar, actualizar, eliminar. Por lo tanto, tengo los siguientes:

  • Para crear un nuevo cliente:
    URI = / customer / {id}, escriba = POST, Nombre de método = Crear cliente ()
  • Para actualizar:
    URI: / customer / {id}, escriba = PUT, method = UpdateCstomer ()
  • Para Eliminar cliente:
    URI = / customer / {id}, escriba = DELETE, Methodname = DeleteCustomer ()
  • Para la vista: URI de
    : / customer / {id}, escriba = GET, method = GetCustomer ()

Ahora, si necesito imprimir un documento para ese cliente, necesito una función de impresión. Mi URI puede verse así: / customer / {id}, escriba = POST, method = PrintCustomer (). Pero he usado ese tipo de URI y POST para CreateCustomer. Quería que el URI se viera así: / customer / Print / {id}, type = POST, method = PrintCustomer ().

Pero no puedo tener el verbo "Imprimir" en mi URI. ¿Cuál es la mejor manera de hacer esto? Pensé en / customer / document / {id} como URI ... pero me encontraré con el mismo problema. Tendría las operaciones de CRUD en el "documento". Así que, de nuevo, me quedo sin lo que usaría para "imprimir". Por favor avise.

    
pregunta Nitya Maha 04.01.2013 - 18:09

3 respuestas

8

POST no significa "crear", significa "proceso". Puede crear un nuevo recurso publicando una solicitud adecuada a un recurso existente (es decir, publicar en /customers para crear un nuevo cliente). Pero también puede usar POST para completar todas las demás acciones que no corresponden a un paradigma CRUD limpio.

En el caso de la impresión, debe considerar el acto de imprimir como un recurso en sí mismo. Le está pidiendo al sistema que cree un "trabajo de impresión" para usted. Esto significa que puede tener un recurso prints/ que actúa como contenedor para todas las impresiones solicitadas. Cuando desea imprimir algo, POST un documento a este recurso que contiene toda la información sobre la impresión que desea crear, identificando los recursos que desea imprimir con enlaces a ellos.

Como documento JSON, podría tener este aspecto:

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

Obviamente, necesitas personalizar esto para que sea relevante para lo que quieres hacer. La clave es que estás identificando otros recursos para imprimir especificando su URL.

En respuesta a la solicitud, simplemente puede devolver un 200 OK o un 204 No-Content y tratarlo como un proceso de incendio y olvido. Sin embargo, si desea mejorarlo, puede devolver 201 Created y especificar la URL del trabajo de impresión recién creado, por ejemplo. /prints/12345 .

Un usuario podría entonces realizar un GET en el recurso para ver el estado de su trabajo de impresión (pendiente, en curso, etc.), o podría solicitar la cancelación del trabajo emitiendo un DELETE .

Una vez que reformule el problema en términos de recursos, el diseño RESTful debería surgir de manera natural y le dará la oportunidad de expandirse y mejorar de maneras que posiblemente no haya considerado de inmediato.

    
respondido por el Paul Turner 04.01.2013 - 18:42
3

He hecho esto antes. Para imprimir un documento acabo de devolver una versión en pdf de un recurso. El cliente solo necesita enviar una solicitud GET para el recurso con la aplicación de cabecera Aceptar / pdf.

Esto también evita crear una nueva URI para un recurso temporal como un trabajo de impresión. El uso del encabezado HTTP también es parte de REST y mantiene el URI limpio.

    
respondido por el imel96 08.01.2013 - 11:23
3

Solo agrega un parámetro al GET actual del URI

Es bastante típico usar un URI para múltiples acciones.

Si está hablando del mismo recurso pero de una acción diferente, lo definiría como un parámetro.

/ customer / {id}? print = true

Luego, cuando define su método GET, detecta la presencia del parámetro de impresión y lo maneja de manera diferente.

REST se define de la siguiente manera:

  • POST: cree un registro, activo o recurso
  • PUT: actualización, un registro, activo o recurso
  • ELIMINAR: elimine un, registro, activo o recurso
Por otra parte,

GET está destinado a ser utilizado de múltiples maneras porque, por lo general, hay muchos formularios diferentes para recuperar un recurso. Es por eso también que las solicitudes GET se representan como una cadena de consulta. Si estuviera trabajando con un recurso de base de datos, literalmente estaría recuperando una vista a través de una consulta, pero REST se abstrae intencionalmente a un nivel superior porque está diseñado para manejar muchos tipos diferentes de recursos.

La especificación REST es bastante avanzada, aunque las API solo están empezando a usarla en gran medida recientemente.

Si está interesado en obtener más información sobre los protocolos REST, le sugiero que lea " Haters Gonna Hate Hate HATEOAS".

Actualizar:

@Shauna señaló un interesante agujero en mi razonamiento. No hay true de forma correcta y muchas formas se consideran aceptables. Lo pensé un poco más y, como su uso previsto es transformar los datos en una representación diferente, tiene sentido definir la transformación como un nuevo tipo MIME.

Por ejemplo, podría representar el URI como:

/customer/{id}+print

Donde podría configurar el tipo de contenido de respuesta para texto / html + imprimir. De esa manera, también tendrías la opción de definir más transformaciones en el futuro.

Por ejemplo:

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

De cualquier manera, todas las formas son aceptables. La implementación que decida depende más de las preferencias personales y de las capacidades de su servidor.

Aparte: Déjame aclarar ya que parece haber algo de confusión. El parámetro de consulta y / o el tipo de contenido 'imprimir' se utiliza para especificar cómo se transforma el recurso. No cómo activar un trabajo de impresión física. Por razones de seguridad, el acceso a nivel de hardware siempre se deja al usuario / cliente / navegador.

    
respondido por el Evan Plaice 04.01.2013 - 21:10

Lea otras preguntas en las etiquetas