Specifica del formato in cui voglio ottenere una risposta tramite POST

Question

Specifica del formato in cui voglio ottenere una risposta tramite POST

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

2

È buona norma consentire a un client di specificare il formato nell'API REST Web:

GET /api/items/123.csv

Tuttavia, non solo GET può restituire una risposta, ma anche POST può fare

Status: 201 Created

{
  mgs: "Your item has created successfully",
  href: "/example.com/items/123"
}

Come dovrebbe apparire URI per una richiesta di POST ( PUT o qualsiasi cosa, ma non GET ) che restituisce una risposta in modo che un client possa specificare il formato in cui desidera che sia la risposta? Ti piace?:

POST /api/items/.csv

Supponiamo che ci sia un errore quando un client invia una richiesta POST e il server deve informare il client su di esso:

Status: 400 Bad Request
{
  mgs: "this is a bad request",
  devMessage: "it's bad because ...."
  friendlyMessage: "something bad happened..."
}

In che formato deve rispondere, perché e come posso specificarlo come client?

P.S. - Sono a conoscenza di REST - Scambi tra negoziazione del contenuto tramite Accept intestazione contro estensioni

architecture rest http web-services

posta Oskar K. 02.10.2013 - 12:14

fonte

3 risposte

Leggi altre domande sui tag architecture rest http web-services

Come posso indicare se un oggetto opera con un altro in un diagramma di classe UML? Un buon nome per ValueObject che contiene l'aggiornamento del database / crea valori di colonna [chiuso]

score 3 · Answer 1

POST /api/items/.csv

sembra logico solo se dai il significato speciale di ".csv". In caso contrario, dovrebbe essere interpretato come POST /api/items/.csv/ dal server che non penso sia ciò che desideri. Sto solo usando questo come esempio in cui l'utilizzo dell'estensione del file non funziona.

Per quanto riguarda ciò che deve essere restituito, il server dovrebbe guardare l'intestazione Accept e rispondere in un formato accettabile se restituisce qualsiasi entità (le risposte 4xx dovrebbero restituire la spiegazione del perché si è verificato un errore).

Penso che dovrebbe essere così:

POST /api/postbox/
Accept: application/json
Content-type: text/csv

Se il server di successo restituisce:

201 Created
Location: /api/items/123.csv

o in caso di errore:

415 Unsupported Media Type
Content-type: application/json
Message-body: { error: "please only post text/csv file." }

score 1 · Answer 2

La domanda che hai collegato descrive cosa fare quando un client GETs da il server, non cosa fare quando il client POSTs a il server.

Nel tuo caso, l'uso dell'intestazione Accept HTTP non funzionerà poiché è l'equivoco di un cliente che dice: "Ehi dammi questa risorsa, ma solo in questi formati."

Questo è un caso in cui si applica il principio di robustezza :

Be conservative in what you do, be liberal in what you accept from others.

Quando il cliente POSTs dei dati dovrebbe contenere un Content-Type che descrive cosa viene consegnato . Ove possibile, la tua applicazione dovrebbe interpretare e accettare il più possibile prima di fallire. Importa se CSV, JSON o XML se l'applicazione può accettarli tutti e tre?

Un singolo URL per la consegna sarà più semplice per i tuoi clienti e molto probabilmente più facile per te. A parte una leggera differenza nel codice per estrarre il contenuto da CSV, JSON, XML, qualunque sia, è più probabile che una volta convertito in un formato che l'applicazione gestisce internamente, i dati saranno trattati allo stesso modo.

score 0 · Answer 3

Perché vuoi inviare un URL dopo una richiesta POST? Di solito ciò che viene fatto è il reindirizzamento alla risorsa appena creata. Ad esempio:

Status: 201 Created
Location: /example/items/123

Tutto questo nelle intestazioni.

Lo stesso per quando si verifica un errore, il codice di stato è sufficiente. 403 Forbidden significa ciò che dice.

Riguardo all'URL POST, l'altra domanda sicuramente risponde.