Estoy implementando un proyecto express.js con Typescript.
He definido una enum y una interface :
export enum ProductType { FOOD = 'food', CLOTH = 'cloth', TOOL = 'tool' } export interface MyProduct { type: ProductType; info: { price: number; date: Date; }; } Uno de los controladores de mi enrutador necesita devolver una matriz de MyProduct al cliente. Intenté esto:
const productArr: MyProduct[] = // call another service returns an array of MyProduct app.get('/products', (req, res) => { res.status(200).send({products: productArr}); });Utilizo Postman para probar este punto final, responde con el estado 200 pero con una página HTML predeterminada en lugar de la matriz de objetos en JSON.
¿Qué echo de menos? ¿Es porque express.js no puede analizar automáticamente la enum y la interface para el objeto json?
PD: configuré el analizador json, por lo que no se trata de eso, otros puntos finales funcionan bien con la respuesta json:
const app = express(); app.use(express.json()); ...Como se menciona en los comentarios, su código debería funcionar. Voy a enumerar algunos pasos que se pueden utilizar para tratar de encontrar el problema.
Configure DEBUG=* en su entorno. DEBUG es una variable de entorno que controla el registro de muchos módulos de Nodo. Podrá ver el flujo de una solicitud a través de Express. Si hay demasiada información, puede limitar la salida así: DEBUG=*,-babel,-babel:*,-nodemon,-nodemon:*,-router:layer,-follow-redirects,-send (use un lista separada por comas y coloque un - delante de cualquier módulo que desee excluir)
Esto debería ayudarlo a rastrear la vida de una solicitud a través de varios enrutadores y rutas. Ahora estás en condiciones de...
El hecho de que esté viendo una página HTML cuando la ruta Express está enviando un objeto podría indicar que su solicitud coincide con una ruta diferente. Busque rutas generales como app.use() que no sea de middleware o rutas comodín que aparezcan ARRIBA de su ruta.
Agregar .status(200) es más código e innecesario.
res.json() Use .json() en lugar de .send() . Si siempre agregará el Content-Type: application/json , mientras que .send() no lo hará cuando no pueda determinar el tipo de contenido (por ejemplo .send(null) o .send('hello') no establecerá el encabezado de tipo de contenido a application/json , lo que puede confundir a los clientes).
Dado que faltan encabezados de respuesta completos y un entorno de servidor , supongamos que está utilizando el servicio de AWS con un proxy inverso . Por lo tanto, puede haber algunas posibilidades enumeradas aquí que deben tenerse en cuenta:
Si el controlador del enrutador devuelve una matriz de objetos pero el cliente no los obtiene en json a través de la respuesta con el estado 200, entonces podría haber un proxy inverso que actúe como un servidor back-end, sirviendo contenido predeterminado con el código de estado 200 para rutas desconocidas del cliente . Entonces, en este escenario, debe incluir en la lista blanca una nueva ruta en su servidor proxy inverso , suponiendo que está utilizando AWS Amplify para la reescritura y redirecciones de API, entonces debe incluir esta ruta en la lista blanca en su configuración de AWS amplificar , o de lo contrario servirá el contenido predeterminado como está sucediendo en el escenario actual.
Si el problema persiste entonces:
Asegúrese de tener la especificación CORS adecuada en su servidor.
Asegúrese de que productArr sea una matriz devuelta por el servicio, porque si algún servicio devuelve este valor, podría ser una promesa no resuelta. Por lo tanto, los casos de prueba adecuados lo ayudarán aquí o, para fines de depuración, configure DEBUG=* en su entorno y asegúrese de que devuelva el valor esperado.
Compruebe si hay otra ruta que esté provocando un cortocircuito en la solicitud: el hecho de que esté viendo una página HTML cuando la ruta Express está enviando un objeto podría indicar que su solicitud coincide con una ruta diferente. Busque rutas generales como app.use() que no sea de middleware o rutas comodín que aparezcan encima de su ruta.