The client consistently makes requests with the accept header of 'application/json' and content-type of 'application/json'
Sì, questa è la cosa giusta da fare, ma non significa che il venditore si preoccupi. Mentre 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 è il caso.
Throughout the project this same practice has been applied across two different vendors and two different services. I found myself having to justify why the services needed to be changed. The vendors stated that the client should cope with this and even my REST library of choice has been questioned (RestEasy) because it doesn't cope with this by default 'out the box'.
Bene, devo essere d'accordo con il venditore. È il loro servizio e finché documentano chiaramente i casi speciali per usarlo, allora non si può davvero imporre che lo cambino. È uno svantaggio per loro dato che gli sviluppatori saranno lenti nell'adottare le loro API e, se ascoltassero ciò di cui hanno bisogno gli sviluppatori, lo cambierebbero, ma purtroppo non c'è alcuna regola che loro debbano seguire gli standard.
The question is am I missing something?
Le intestazioni di richieste 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 delle richieste. Posso rispondere con quello che voglio. Mentre un servizio configurato in IIS con C # offre una gestione molto più semplice delle intestazioni delle richieste, del loro tipo e della gestione del tipo di risposta. Ha molto a che fare con gli strumenti utilizzati dal venditore per costruire l'API.
I'm I being pedantic about this?
Sì e No. Ho amici sviluppatori che non sarebbero in grado di superare questo. Diventerebbero così fissi dal problema e incapaci di procedere con altre attività finché l'API non funzionasse nel modo in cui si aspettavano che funzionasse. Ora è pedante.
È un problema perché il venditore ha creato "più lavoro" per completare le tue attività. Chiunque sarebbe frustrato da questo. So che lo sarei.
Is it OK to have a JSON API that doesn't have a content-type of application/json in this scenario?
Assolutamente, ma non è una buona pratica.
Un client può solo dire al server qual è il tipo di contesto di request . Non ha la capacità di imporre un tipo di contenuto per response . Il client può solo informare il server che sarà accept una raccolta di possibili tipi di contenuto.
Definizioni dei campi di intestazione
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
È possibile che un cliente richieda un'immagine di image/jpeg , ma le risposte del server con text/html e un codice di stato di 404 se l'immagine non è stata trovata. I server possono anche rispondere in modo errato. Esistono molti siti Web Wordpress che rispondono con text/html e codice di stato 200 per le pagine file non trovate.
Questa è la pratica BAD sulla 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.
References would be appreciated. How do you resolve this situation from a commercial point of view?
Ho incontrato questo problema su alcuni progetti. Hai post di dati JSON sul server e restituisce una risposta JSON o HTML.
In realtà non è un grosso problema sapere quale tipo era nella risposta. Se il primo carattere è { o [ puoi assumere JSON. Se è < puoi assumere HTML. È così che l'ho gestito in passato. A volte il programmatore che ha scritto l'API sa tutto riguardo le intestazioni HTTP. Tutto torna come text/html risposte. Se sei fortunato hanno Apache configurato per default su text/plain che a volte può aiutare.
Questi problemi esistono e continueranno a esistere molto nel futuro. La comunicazione da server a server è di gran lunga un'attività non regolamentata. Non esiste un ente governativo che esca un fornitore da un sindacato per un server che fornisce risposte HTTP sbagliate.