Qual è lo scopo degli URI RESTful per i metodi POST / PUT / PATCH / DELETE?

Question

Qual è lo scopo degli URI RESTful per i metodi POST / PUT / PATCH / DELETE?

#1 da (4 voti)
#2 da (2 voti)

1

Nel processo di ideazione di un framework per applicazioni web, ho passato un po 'di tempo a riflettere sulla nozione di percorsi RESTful. Se volessi creare per es. un nuovo argomento, potrei inviare una richiesta POST a / topics. I suoi parametri potrebbero essere qualcosa come: { topic: { body: 'Body' } }

Come tale, il tipo di risorsa che si sta creando può essere desunto dai parametri. Poiché esiste l'argomento di livello superiore "argomento", possiamo verificare logicamente che la richiesta è di creare un argomento.

Per me, la cosa strana è che la creazione POST è l'unica azione che cade al di fuori della nozione di una risorsa singolare o di una collezione. Non è forse né l'uno né l'altro. Certo, stai aggiungendo a una raccolta, ma al contrario di dire a GET index non stai recuperando alcuna parte di quella raccolta, e lo stato di quella raccolta in larga misura è irrilevante. A differenza di GET , PUT/PATCH o DELETE , non stai recuperando un oggetto singolare basato su un identificatore. Stai creando un articolo in cui uno non esiste.

Ho concepito un servizio di "master registrar" che rispondeva a tutte le richieste in entrata di POST . Immagina ogni forma POST ing a / , con il registrar principale che determina la risorsa prevista in base ai parametri e rimanda ai servizi esistenti allo scopo di mantenere una risorsa basata su tali parametri.

In effetti, per qualsiasi azione non GET, i percorsi diventano irrilevanti. Non sembrano avere un importante scopo semantico. Un utente non ha intenzione di collegarsi all'URL di un'azione di un modulo. Anche nel caso di PUT , PATCH o DELETE Il tipo di risorsa che si sta creando o la risorsa che si sta modificando può essere desunta dai parametri. Ad esempio, se stessimo modificando un argomento rispetto a crearne uno, i parametri potrebbero essere { topic: { id: 1, body: 'New Body'} } . La presenza di un ID nei parametri indica che l'argomento in questione esiste già e deve essere recuperato prima di tutto.

Non so se questo è RESTful o no. Indipendentemente da ciò, non riesco a capire perché questo approccio sia non valido o sconsigliabile. Data la mia prudenza e ingenuità, tuttavia, mi piacerebbe sapere perché potrebbe essere.

web-development rest web-applications

posta AvidArcher 25.07.2014 - 06:22

fonte

2 risposte

Leggi altre domande sui tag web-development rest web-applications

UML Class Diagram: come posso rappresentare generalizzazioni "ortogonali" (o multi-ereditarietà)? Instantiating objects in Java [closed]

score 4 · Answer 1

Nella maggior parte delle API REST, il tipo di oggetto non è incorporato nel payload. Questo è il lavoro del risolutore di risorse. Il tuo "master registrar" è equivalente al tipico resolver di percorso presente nei server web, tranne che per l'utilizzo di tipi embedded anziché di percorsi.

Quindi invece del tuo formato:

POST    /
{
    topic:
    {
        property1: "value1",
        property2: "value2",
        ...
    }
}

usa questo:

POST    /topics
{
    property1: "value1",
    property2: "value2",
    ...
}

Ciò manterrà il tuo progetto DRY pur sfruttando il più possibile il codice built-in standard.

Per quanto riguarda le specifiche, POST è il metodo "tutto il resto", utilizzato per qualsiasi elaborazione che non si adatta alla semantica di GET, PUT, PATCH e DELETE. Quindi non violerebbero la lettera della specifica, ma potresti comunque confondere potenziali clienti dei tuoi servizi a causa dell'API non standard.

score 2 · Answer 2

La definizione della specifica HTTP di POST è molto ampia. Ci sono due clausole che lo rendono buono da trattare come il verbo "crea".

È il metodo per "accodare" a un database
È il metodo per l'"elaborazione dati" generale

Quindi per REST, il senso del POST è che è per accodare a una collezione di risorse.

Nel tuo esempio, POST a "/ topics" è perfettamente valido - perché stai creando davvero un singolo oggetto, ma estendi la collezione di tutti gli elementi. In realtà l'obiettivo è la collezione. C'è un po 'di elaborazione dei dati lungo la strada.

POST a "/" e inferire il tipo potrebbe effettivamente essere OK secondo la specifica HTTP. In un certo senso, dovresti creare un elemento e aggiungerlo alla raccolta di tutti gli elementi (!). Ma IMHO ha più senso limitare l'azione alla giusta risorsa & basta pubblicare su / topic.

È difficile definire quello che non dovrebbe fare con il POST ... ricorda che il World Wide Web è stato creato con GET e POST. Ci sono casi in cui è meglio ottenere con un POST che con un GET, se la query è lunga o utilizza dati strutturati. Fondamentalmente, se vuoi far navigare una nave da guerra attraverso una feritoia in REST, usa post.

(O, come ha pubblicato Roy Fielding, POST è il verbo da usare quando non vuoi generalizzare l'operazione.)

Stai attento a confondere i tuoi clienti. POST a "/ topics" invece di "/" potrebbe avere più senso.