El cliente realiza constantemente solicitudes con el encabezado de aceptación de 'application / json' y el tipo de contenido de 'application / json'
Sí, esto es lo correcto, pero no significa que al proveedor le importe. Si bien entiendo totalmente su frustración, porque también creo que un servicio JSON siempre debe dar una respuesta JSON, pero hay muchos ejemplos en los que ese no es el caso.
A lo largo del proyecto, esta misma práctica se ha aplicado en dos proveedores diferentes y dos servicios diferentes. Me encontré teniendo que justificar por qué los servicios necesitaban ser cambiados. Los proveedores declararon que el cliente debería hacer frente a esto e incluso mi biblioteca REST elegida ha sido cuestionada (RestEasy) porque no hace frente a esto de forma predeterminada 'fuera de la caja'.
Bueno, tengo que estar de acuerdo con el vendedor. Es su servicio y siempre y cuando documenten claramente los casos especiales para usarlo, no se puede imponer que lo cambien. Es una desventaja para ellos, ya que los desarrolladores tardarán en adoptar su API, y si escucharan lo que los desarrolladores necesitan, lo cambiarían, pero lamentablemente no hay una regla que deba seguir los estándares.
La pregunta es ¿me estoy perdiendo algo?
Los encabezados de solicitud no significan nada a menos que se interrumpan correctamente en el otro extremo. Sé que si desarrollo una API web con PHP, al diablo con los encabezados de solicitud. Puedo responder con lo que quiera. Mientras que un servicio configurado en IIS con C # ofrece un manejo mucho más fácil de los encabezados de solicitud, su tipo y el tipo de respuesta. Tiene mucho que ver con las herramientas que el proveedor usó para construir la API.
¿Estoy siendo pedante sobre esto?
Sí y no. Tengo amigos desarrolladores que no podrían superar esto. Estarían tan obsesionados con el problema y no podrían continuar con otras tareas hasta que la API funcione de la manera que esperan que funcione. Ahora eso es ser pedante.
Es un problema porque el proveedor ha creado "más trabajo" para completar sus tareas. Cualquiera se sentiría frustrado por eso. Sé que lo estaría.
¿Está bien tener una API JSON que no tenga un tipo de contenido de aplicación / json en este escenario?
Absolutamente, pero no es una buena práctica.
Un cliente solo puede decirle al servidor cuál es el tipo de contexto de a request. No tiene la capacidad de imponer un tipo de contenido para el response. El cliente solo puede informar al servidor que hará acceptuna colección de posibles tipos de contenido.
Definiciones de campo de encabezado
El campo Aceptar encabezado de solicitud se puede usar para especificar ciertos tipos de medios que son aceptables para la respuesta. Los encabezados de aceptación se pueden usar para indicar que la solicitud está específicamente limitada a un pequeño conjunto de tipos deseados, como en el caso de una solicitud de una imagen en línea.
Es posible que un cliente solicite una imagen de image/jpeg, pero el servidor responde con text/htmly un código de estado de 404si la imagen no se encontró. Los servidores también pueden responder incorrectamente. Hay muchos sitios web de Wordpress que responden con un text/htmlcódigo de estado 200para archivos que no se encuentran páginas.
Ahora, eso es una práctica MALA por parte del servidor. Lo que intento decirte es que es absolutamente posible, y sucede a menudo. Las personas no saben lo que hacen cuando configuran estas cosas.
Se agradecerán las referencias. ¿Cómo se resuelve esta situación desde un punto de vista comercial?
Me he encontrado con este problema en algunos proyectos. Usted postenvía datos JSON al servidor y le devuelve una respuesta JSON o HTML.
Realmente no es un gran problema saber qué tipo estaba en la respuesta. Si el primer carácter es {o [puede asumir JSON. Si es así, <puede asumir HTML. Así lo he manejado en el pasado. A veces, el programador que escribió la API sabe todo sobre los encabezados HTTP. Todo vuelve como text/htmlrespuestas. Si tiene suerte, tienen Apache configurado por defecto, lo text/plainque a veces puede ayudar.
Estos problemas existen y continuarán existiendo en el futuro. La comunicación de servidor a servidor es, con mucho, una actividad no regulada. No existe un organismo rector que expulse a un proveedor de un sindicato por un servidor que dé malas respuestas HTTP.