Gestionar soporte para Internacionalización en mi API REST

En esta Wiki se va a tratar el uso de las cabeceras HTTP para negociar de forma automática el idioma en el que nuestra API REST devolverá los datos.
En este contexto, solo tiene sentido gestionar el idioma si ya disponemos de todos los literales traducidos con anterioridad y almacenados en ficheros de propiedades o en base de datos:

• Gestionar soporte para internacionalización en mi proyecto
  • Internacionalización en la BBDD con Hibernate
  • Internacionalización (i18n) de campos con Hibernate

Para negociar el idioma en nuestro servicio REST hay que hacer uso de las siguientes cabeceras HTTP definidas en el RFC 2616 - Hypertext Transfer Protocol HTTP/1.1:

• Accept-Language
• Content-Language

Cabecera HTTP establecida por el cliente en la petición para indicar la preferencia en el idioma de la información a devolver.
Puede añadirse varios idiomas separados por comas donde el orden significa la prioridad en el idioma.

   Accept-Language: es, en-gb, en     

Esta cabecera indica que se prefiere el idoma Español (es), pero que también se aceptan el inglés británico o cualquier otro tipo de inglés.

Cabecera HTTP establecida por el servicio en la respuesta para indicar los idiomas soportados.

   Content-Language: en, es

Esta cabecera indica que el servicio soporta los idiomas inglés y español. Por lo tanto, en el ejemplo de la petición anterior, el servicio devolverá la información en español.

Mediante el uso de estas cabeceras, el cliente puede interrogar al servicio y proporcionarle al usuario la posibilidad de escoger un idioma entre los soportados.

A continuación se muestra un ejemplo de servicio REST con Jersey donde se establece automáticamente el idioma de la respuesta a partir de la cabecera de la petición.
Para este ejemplo se usarán los ficheros de mensajes de FundeWeb.

  ...
  	//@Context
	//HttpServletRequest request;
  ...
	@GET
	@Path( "/bienvenida" )
	@Produces(MediaType.TEXT_PLAIN)
	public Response testLanguage( @QueryParam( "nombre" ) String nombre ) {
 
		//Locale requestLocale = request.getLocale();
		String cadena = Messages.instance().get("org.jboss.seam.loginSuccessful" );
		String mensaje = MessageFormat.format( cadena, nombre );
 
		return Response.ok( mensaje ).header( "Content-Language", "es, en" ).build();
	}
  ...

En este ejemplo no sería necesario incluir el objeto request para obtener el locale. Con ficheros de propiedades la selección del idioma se realiza automáticamente una vez se ha establecido la cabecera en la petición.
Se mantiene el código comentado para indicar cómo obtener el locale en el caso de querer usarlo como parámetro en consultas de base de datos.

 GET /proyectoPrueba/rest/public/v2/bienvenida?nombre=RAMÓN HTTP/1.1
 Host: ramongg.atica.um.es:8002
 Accept-Language: es

 Bienvenido, RAMÓN

 Date: Mon, 15 Jun 2020 10:54:45 GMT
 Transfer-Encoding: chunked
 Content-Type: text/plain
 Content-Language: es, en

 GET /proyectoPrueba/rest/public/v2/bienvenida?nombre=RAY HTTP/1.1
 Host: ramongg.atica.um.es:8002
 Accept-Language: en

  Welcome, RAY!
 
  Date: Mon, 15 Jun 2020 10:55:22 GMT
  Transfer-Encoding: chunked
  Content-Type: text/plain
  Content-Language: es, en

• RFC HTTP - Cabeceras
• How to localize your API

Pon aquí tus propuestas de FAQs, indicando qué problema tienes, y buscaremos la solución lo antes posible. Si además lo has resuelto, puedes indicar cómo lo has hecho.

Formato de petición de FAQ:

**Título**
//Descripción del problema//
//Tecnología afectada (Fundeweb 1/2)//
//Cómo reproducir el error//
**Solución**
//Descripción de la solución//

Tus datos de contacto  --- //[[correo@umOticarum.es|Tu Nombre]] dd/mm/yyyy //

— RAMON GINEL GEA 15/06/2020 13:16