Feature #43247
Request respects format
| Status: | Closed | Start date: | 2012-11-23 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assigned To: | Bastian Waidelich | % Done: | 0% |
|
| Category: | Error | |||
| Target version: | - | |||
| PHP Version: | Complexity: | |||
| Has patch: | No |
Description
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.
https://github.com/pankajlele/t3con12asia/blob/master/FLOW3Application/Packages/Application/Lelesys.EventsExample/Configuration/Settings.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
History
#1 Updated by Adrian Föder over 2 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...
#2 Updated by Carsten Bleicker over 2 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?
#3 Updated by Carsten Bleicker over 2 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.
#4 Updated by Bastian Waidelich almost 2 years ago
- Category set to Error
- Status changed from New to Closed
- Assigned To 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)