Feature #43247

Request respects format

Added by Carsten Bleicker almost 9 years ago. Updated about 8 years ago.

Could have
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Has patch:


hi folks,
right at this point i am thinking about a REST Service.
And i asked myself: Shouldn't also exceptions/notfound/etc also returned
in the requested format (f.e. xml/json) by default? Maybe not all formats but
the most needed, json f.e.?

Found something where this happens by changing the notFoundController through yaml.
But is a systemwide change realy needed here or shouldnt it be possible to configure this
per package?

how would you deliver notFound in a REST Service and also Exceptions etc.
is it a good idea to deliver html exceptions/notfound to the rest client?

Related issues

Related to TYPO3.Flow - Feature #43569: Exception Handler should respect formatClosedBastian Waidelich2012-12-042013-04-13


Updated by Adrian Föder almost 9 years ago

good question; in my opinion I would say, a REST client doesn't need the reason for an exception, the error code must be enough. 404, 500, ... The error codes themselve already tell as much as a client needs to know...


Updated by Carsten Bleicker almost 9 years ago

mhh, what do you think about:
switch from REST v1 to v2 and old v1 throws exception "Support for this Service ends. Please do ... blah".
no case for json exception?


Updated by Carsten Bleicker over 8 years ago

as descriped here (see error of v2): http://de.wikipedia.org/wiki/JSON-RPC
in my opinion its very usefull for the user of a json api to get an information about whats going wrong
and handle the error maybe in a log file.


Updated by Bastian Waidelich about 8 years ago

  • Category set to Error
  • Status changed from New to Closed
  • Assignee set to Bastian Waidelich

Hi Carsten,

I'm closing this as duplicate of #43569 even though this one was older (I didn't see it before) because the other issue is bound to the "REST work package".
Please keep the feedback coming in #43569 - I'm still not perfectly sure what a good JSON/XML error could look like, especially as you didn't want to render the message of an exception (in production context)

Also available in: Atom PDF