Accept header

53 views
Skip to first unread message

Fabrice Theytaz

unread,
Mar 30, 2016, 9:10:59 AM3/30/16
to Europass Interoperability
Hi all, (sorry for my bad english)

It would be nice if the REST service accept the Accept header for select the format of error responses.

I have tried this:

curl -k https://europass.cedefop.europa.eu/rest/v1/document/to/pdf
-H "Content-Type: application/xml" -H "Accept: application/pdf, application/json"
-d @xml-with-error.xml -o response.json

But I got XML format error

Fabrice

Europass Interoperability

unread,
Mar 31, 2016, 7:46:09 AM3/31/16
to Europass Interoperability
Hi Fabrice,

Thank you for your message and you interest in Europass.

Currently, the format of the error responses is determined from the Content-Type header only, the Accept header has no effect. For example:

$ curl https://europass.cedefop.europa.eu/rest/v1/document/to/pdf -H "Content-Type:application/xml" -d @invalid.xml

<?xml version='1.0' encoding='UTF-8'?><Error><trace>ErrCode:ewad_2r_U4WmvJS3</trace><code>download.input.empty</code><message>The input is undefined or empty.</message></Error>

$ curl https://europass.cedefop.europa.eu/rest/v1/document/to/pdf -H "Content-Type:application/json" -d @invalid.xml

{
 
"Error" : {
   
"trace" : "ErrCode:ewad_2r_gQNXrtvy",
   
"code" : "download.input.empty",
   
"message" : "The input is undefined or empty."
 
}
}

More specifically:
  • When Content-Type:application/xml => Error is always in XML
  • When Content-Type:application/json => Error is always in JSON
  • When Content-Type is set to something different than XML or JSON (e.g. Content-Type:application/pdf in the case of the /document/extraction endpoint) => Error is always XML
  • When the Content-Type header is missing from the request => Error is always XML
This is a design decision, based on the rationale that the majority of our users would normally want to get back the error in the same format with the document being uploaded to the web service. We had considered the Accept header when we were developing the REST API, but eventually decided to not support it so as to keep things as simple as possible.

That said, could you please provide us with a few more details on why exactly you prefer to get back a JSON response even though your input file is in XML? (For example, you could have selected to use JSON for the input file too, so that you have to deal with one format only). This way, we can better assess your use case and perhaps reconsider some initial design decisions.

Thanks a lot,

Dimitris Zavaliadis
Team Europass

Fabrice Theytaz

unread,
Jul 31, 2016, 7:47:57 PM7/31/16
to Europass Interoperability
Hi, sorry for the late reply (I had forgotten my post)

Yes it is not a problem to have multiple answer formats and your approach is logical.

This is just to make life easier for developers;-) I actually wanted to test Android and I could not parse XML :-( that's why I asked only the JSON... but now it ' is good so I can manage two formats;-)

Thank you for your reply
Reply all
Reply to author
Forward
0 new messages