Il client effettua costantemente richieste con l'intestazione accetta di "application / json" e il tipo di contenuto di "application / json"
Sì, questa è la cosa corretta da fare, ma non significa che il fornitore si preoccupi. Anche se capisco perfettamente la tua frustrazione, perché penso anche che un servizio JSON dovrebbe sempre dare una risposta JSON, ma ci sono molti esempi in cui non è così.
Durante tutto il progetto questa stessa pratica è stata applicata a due diversi fornitori e due diversi servizi. Mi sono ritrovato a dover giustificare il motivo per cui i servizi dovevano essere cambiati. I venditori hanno dichiarato che il cliente dovrebbe far fronte a questo e anche la mia libreria REST di scelta è stata messa in discussione (RestEasy) perché non lo fa di default "out the box".
Bene, devo essere d'accordo con il venditore. È il loro servizio e fintanto che documentano chiaramente i casi speciali per usarlo, non puoi davvero imporre che lo cambino. È uno svantaggio per loro in quanto gli sviluppatori saranno lenti ad adottare la loro API e se ascoltassero ciò di cui gli sviluppatori hanno bisogno, lo cambieranno, ma purtroppo non c'è alcuna regola che debbano seguire gli standard.
La domanda è: mi sto perdendo qualcosa?
Le intestazioni della richiesta non significano nulla a meno che non vengano interrotte correttamente dall'altra parte. So che se sviluppo un'API Web utilizzando PHP, allora al diavolo le intestazioni della richiesta. Posso rispondere con quello che voglio. Considerando che, un servizio configurato in IIS con C # offre una gestione molto più semplice delle intestazioni di richiesta, il loro tipo e la gestione del tipo di risposta. Ha molto a che fare con gli strumenti utilizzati dal fornitore per creare l'API.
Sono pedante per questo?
Sì e No. Ho amici degli sviluppatori che non sarebbero in grado di superarlo. Sarebbero così risolti dal problema e incapaci di procedere con altre attività fino a quando l'API funziona nel modo previsto. Questo è pedante.
È un problema perché il fornitore ha creato "più lavoro" per completare le attività. Chiunque ne sarebbe frustrato. So che lo sarei.
È corretto avere un'API JSON che non ha un tipo di contenuto di application / json in questo scenario?
Assolutamente, ma non è una buona pratica.
Un client può solo dire al server qual è il tipo di contesto di a request. Non ha la capacità di imporre un tipo di contenuto per il response. Il client può solo informare il server che sarà acceptuna raccolta di possibili tipi di contenuto.
Definizioni dei campi di intestazione
Il campo Accetta intestazione richiesta può essere utilizzato per specificare alcuni tipi di supporti che sono accettabili per la risposta. Le intestazioni Accetta possono essere utilizzate per indicare che la richiesta è specificamente limitata a un piccolo set di tipi desiderati, come nel caso di una richiesta per un'immagine in linea.
È possibile per un client richiedere un'immagine di image/jpeg, ma il server risponde text/htmle un codice di stato 404se l'immagine non è stata trovata. I server possono anche rispondere in modo errato. Ci sono molti siti Web Wordpress là fuori che rispondono con text/htmle codice di stato 200per le pagine di file non trovati.
Ora questa è tutta una cattiva pratica da parte del server. Quello che sto cercando di dirti è che è assolutamente possibile e succede spesso. Le persone non sanno cosa stanno facendo quando configurano queste cose.
I riferimenti sarebbero apprezzati. Come risolvi questa situazione da un punto di vista commerciale?
Ho riscontrato questo problema in alcuni progetti. Si postdati JSON al server e restituisce una risposta JSON o HTML.
Non è davvero un grosso problema sapere quale tipo era nella risposta. Se il primo carattere è {o [puoi assumere JSON. In tal caso, <puoi assumere HTML. È così che l'ho gestito in passato. A volte il programmatore che ha scritto l'API sa tutto sulle intestazioni HTTP. Tutto ritorna come text/htmlrisposte. Se sei fortunato hanno Apache configurato per impostazione predefinita a text/plaincui a volte può aiutare.
Questi problemi esistono e continueranno ad esistere in futuro. La comunicazione da server a server è di gran lunga un'attività non regolamentata. Non esiste un organo di governo che espellerà un fornitore da un sindacato per un server che fornisce risposte HTTP errate.