Cosa includere nei risultati / errori POST / PATCH (batch) per i risultati dell'API REST pragmatica

0

Questa è davvero una domanda sulle pratiche "migliori" o "pratiche" e sarebbe interessata se qualcun altro ha avuto un bisogno simile a me stesso e come lo hanno gestito.

Ho un'API REST (ish) che abbiamo sviluppato per "imbastire" la parte anteriore di un sistema legacy esistente. Uso questa API "REST" per consentire a entrambe le terze parti e alle nostre prossime applicazioni mobili di interagire con il nostro sistema esistente.

Prendo un approccio pragmatico (ecco perché uso il termine RESTish), dove seguo le linee guida REST nel miglior modo possibile, ma non lasciarlo intralciare se ho bisogno di allontanandoci da loro per soddisfare le nostre esigenze di business (e il fatto che sia imbullonato sul fronte di un sistema legacy). Se faccio qualcosa non "puro REST", allora così sia.

Quando si creano richieste POST, sembra comune restituire l'intero record (oggetto) nella risposta al POST . Al momento non lo faccio, perché in realtà non vedo il valore nei nostri casi d'uso, ma mi è stato detto che forse dovrei esserlo. Inoltre, nei pochi casi utilizzerò un POST batch (molti record, ad esempio un'app client offline in arrivo online), restituendo ogni singolo oggetto nuovamente incluso nel batch (specialmente per un'app client mobile), mi sembra semplicemente inutile.

Altri luoghi, ho anche visto accennato, che perhap si restituisce semplicemente un "link" al nuovo oggetto (es. URL all'oggetto "creato"), o forse qualche nota "chiave" o Id. Il nostro problema è, il modo in cui il sistema funziona la "forma" di JSON dati di carico utile utilizzata nella richiesta REST è persa, poiché la richiesta viene passata sul sistema legacy (nel nostro caso tramite chiamate in stile RPC), quindi se volessi restituire gli oggetti JSON originali, dovrei forse serializzarli su una stringa e passarli fino in fondo così posso aggiungerlo al servizio di front-end REST una volta che torna dal sistema legacy. Preferirei davvero NON farlo.

La mia domanda è, è davvero così brutto che NON restituire una risorsa creata (o talvolta solo una risorsa aggiornata) nello stesso formato in cui è POSTATA? È altrettanto valido restituire una sorta di Id o chiave?

Grazie in anticipo per qualsiasi suggerimento qui!

    
posta peterc 07.11.2018 - 03:16
fonte

1 risposta

4

is it really that bad NOT to return a created resource ... in the same format it is POSTED?

HTTP ti dà davvero molta libertà nel modo in cui rispondi ai messaggi.

Ad esempio, la sezione che specifica il 200 codice di risposta OK descrive il tipo di rappresentazioni potresti vedere nel corpo della risposta.

POST a representation of the status of, or results obtained from, the action;

"la rappresentazione dello stato dell'azione potrebbe essere solo

Congratulations! we created a resource.

Non c'è nulla nella semantica dell'operazione che dice che devi restituire una rappresentazione della risorsa creata.

Anche se non acquisti quell'argomento ....

in the same format it is POSTED?

L'esempio di Ur di un'applicazione REST è il world wide web. Scarichiamo un modulo, lo inseriamo e lo inoltriamo. Nella maggior parte dei casi, il contenuto del modulo raggiunge il server come una raccolta application/x-www-form-urlencoded di coppie di valori chiave. Quanto spesso ricevi uno di quei back dal server? Mai, o qualche approssimazione, perché le risposte tornano in text/html (o qualche variante simile).

Se il tuo "approccio pragmatico" può indicare un precedente sul world-wide-web, è probabile che tu stia su un terreno solido.

    
risposta data 07.11.2018 - 04:08
fonte

Leggi altre domande sui tag