search

mia-platform / crud-service

A lightweight application to expose restful CRUD API over HTTP interface
https://docs.mia-platform.eu/docs/how_to/crud_service/crud_oss_usage
Apache License 2.0
44 stars 4 forks source link

Export default response format does not align with documentation #319

Closed marco-basso closed 5 months ago

marco-basso commented 5 months ago

Description The default response of the crud /export endpoint does return a json instead of an ndjson as described within the documentation: https://github.com/mia-platform/crud-service/issues

Environment I'm using CRUD Service version 6.9.1

Minimal Reproduction To reproduce the problem you need to run the crud-service with version 6.9.1 and curl the export endpoint on a generic collection without any accept header.

marco-basso commented 5 months ago

After a further analysis also the crud-service versions 6.9.6, 6.10.0, 7.0.2 do respond with a json on the /export endpoint.

I am expecting that the default response is ndjson as stated in the documentation.

We are having problems because the export-service which depends on the crud-service /export endpoint does expect an ndjson response.

If this issue will be handled, the export service will not have any problem. Otherwise I will need to open an issue on the export-service to adapt the /export request.

ianFar96 commented 5 months ago

Hi, have you tried to specify the header accept to application/x-ndjson? you may have it set to application/json if the return value is a json

danibix95 commented 5 months ago

Hi! Have you checked how your service is calling the /export route of the collection of interest?

According to the code, in case no Accept header (or any value */*) is provided then the content-type application/x-ndjson is employed.

I tried it starting the CRUD Service locally with

npm run start:local

and I obtained the following output when calling the export endpoint:

❯ curl -v http://localhost:3000/books-endpoint/export
*   Trying 127.0.0.1:3000...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET /books-endpoint/export HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/x-ndjson
< Date: Fri, 24 May 2024 14:25:14 GMT
< Connection: keep-alive
< Keep-Alive: timeout=72
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

As highlighted by the request trace, when the Accept header is not specified (*/*) the returned content-type is application/x-ndjson.

marco-basso commented 5 months ago

I have tried with a curl and it does return the proper header. I don't know why the tool I am using to do http requests does inject an application/json accept header when none is passed.

Sorry for the bothering, and thank you for your response ^^