Rappresenta le azioni (verbi) nell'URI REST

Question

Rappresenta le azioni (verbi) nell'URI REST

#1 da (8 voti)
#2 da (3 voti)
#3 da (3 voti)

14

Ho un'operazione di stampa da eseguire per i miei documenti cliente. Ho bisogno anche delle altre operazioni standard, come aggiungere, aggiornare, cancellare. quindi, ho seguito:

Per la creazione di un nuovo cliente: URI di rete = / cliente / {id}, tipo = POST, Methodname = CreateCustomer ()
Per l'aggiornamento:
URI: / customer / {id}, type = PUT, method = UpdateCstomer ()
Per Elimina cliente:
URI = / cliente / {id}, tipo = DELETE, Methodname = DeleteCustomer ()
Per la visualizzazione: URI
: / cliente / {id}, tipo = GET, metodo = GetCustomer ()

Ora, se ho bisogno di stampare un documento per quel cliente, ho bisogno di una funzione di stampa. L'URI potrebbe essere simile a: / customer / {id}, type = POST, method = PrintCustomer (). Ma ho usato quel tipo di URI e POST per CreateCustomer. Volevo che l'URI assomigliasse a questo: / cliente / Stampa / {id}, tipo = POST, metodo = PrintCustomer ().

Ma non posso avere il verbo "Stampa" nel mio URI. qual'è il miglior modo per farlo? Ho pensato a / customer / document / {id} come all'URI ... ma mi imbatterò nello stesso problema. Avrei le operazioni CRUD sul "documento". Quindi, di nuovo, ho esaurito ciò che avrei usato per "stampare". Si prega di avvisare.

rest

posta Nitya Maha 04.01.2013 - 18:09

fonte

3 risposte

Leggi altre domande sui tag rest

Utilizzerebbe una tabella hash nella garbage collection per risolvere il problema mondiale di mark e sweep? Micro-servizi e replica dei dati

score 8 · Answer 1

POST non significa "crea", significa "processo". Puoi creare una nuova risorsa pubblicando una richiesta adatta a una risorsa esistente (ad es. Post in /customers per creare un nuovo cliente). Ma puoi anche usare POST per riempire tutte le altre azioni che non corrispondono ad un paradigma CRUD pulito.

Nel caso della stampa, dovresti considerare l'atto di stampare come una risorsa stessa. Stai chiedendo al sistema di creare un "lavoro di stampa" per te. Ciò significa che puoi avere una risorsa prints/ che funge da contenitore per tutte le stampe richieste. Quando si desidera stampare qualcosa di POST di un documento su questa risorsa che contiene tutte le informazioni sulla stampa che si desidera creare, identificando le risorse che si desidera stampare con i collegamenti ad esse.

Come documento JSON, potrebbe essere simile a questo:

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

Ovviamente, devi personalizzarlo per essere rilevante per ciò che vuoi fare. La cosa fondamentale è che stai identificando altre risorse da stampare specificando il loro URL.

In risposta alla richiesta, potresti semplicemente restituire un 200 OK o un 204 No-Content e trattarlo come un processo fire-and-forget. Tuttavia, se si desidera migliorarlo, è possibile restituire 201 Created e specificare l'URL del lavoro di stampa appena creato, ad es. /prints/12345 .

Un utente può quindi eseguire un GET sulla risorsa per vedere lo stato del suo lavoro di stampa (in sospeso, in corso, ecc.) o può richiedere l'annullamento del lavoro emettendo un DELETE .

Una volta riformulato il problema in termini di risorse, il progetto RESTful dovrebbe venire in modo naturale e darti l'opportunità di espanderlo e migliorarlo in modi che potresti non aver preso immediatamente in considerazione.

score 3 · Answer 2

L'ho già fatto prima. Per stampare un documento, restituisco solo una versione pdf di una risorsa. Il client deve solo inviare una richiesta GET per la risorsa con Accept header application / pdf.

Questo evita anche di creare un nuovo URI per risorse temporanee come il lavoro di stampa. Anche l'utilizzo dell'intestazione HTTP fa parte di REST e mantiene pulito l'URI.

score 3 · Answer 3

Basta aggiungere un parametro al GET dell'URI corrente

È piuttosto tipico usare un URI per più azioni.

Se parli della stessa risorsa ma di un'azione diversa, la definiresti come parametro.

/ cliente / {id}? Print = true

Quindi, dove definisci il tuo metodo GET, rilevi la presenza del parametro di stampa e lo gestisci in modo diverso.

REST è definito nel seguente modo:

POST - Crea un record, risorsa o risorsa
PUT - Aggiornamento, record, risorsa o risorsa
DELETE - Rimuovi un, record, risorsa o risorsa

GET, d'altra parte, è pensato per essere utilizzato in più modi, perché in genere ci sono molte forme diverse che una risorsa può essere recuperata. Questo è anche il motivo per cui le richieste GET sono rappresentate come una stringa di query. Se lavorassi con una risorsa database, dovresti letteralmente recuperare una vista tramite una query, ma REST viene intenzionalmente astratto a un livello superiore perché è progettato per gestire diversi tipi di risorse.

La specifica REST è abbastanza lungimirante, anche se le API stanno solo recentemente iniziando a usarlo pesantemente.

Se sei interessato a saperne di più sui protocolli REST ti consiglio caldamente di leggere " Haters Gonna Hate HATEOAS ".

Aggiornamento:

@Shauna ha evidenziato un buco interessante nel mio ragionamento. Non c'è un vero giusto modo e molte forme sono considerate accettabili. Ci ho pensato un po 'di più e dato che il tuo scopo è quello di trasformare i dati in una rappresentazione diversa, ha senso definire la trasformazione come un nuovo tipo MIME.

Ad esempio, potresti rappresentare l'URI come:

/customer/{id}+print

Dove puoi impostare la risposta Content-Type su text / html + print. In questo modo avresti anche la possibilità di definire più trasformazioni in futuro.

Ad esempio:

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

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

In ogni caso, tutte le forme sono accettabili. L'implementazione che decidi dipende più dalle preferenze personali e dalle capacità del tuo server.

A parte: permettimi di chiarire perché sembra che ci sia una certa confusione. Il parametro di query "print" e / o il tipo di contenuto vengono utilizzati per specificare il modo in cui la risorsa viene trasformata. Non come attivare un lavoro di stampa fisico. Per motivi di sicurezza, l'accesso a livello di hardware è sempre lasciato all'utente / client / browser.