Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

for Rest API how can i change default response behaviour #3966

Closed
mithun12000 opened this issue Jun 19, 2014 · 11 comments
Closed

for Rest API how can i change default response behaviour #3966

mithun12000 opened this issue Jun 19, 2014 · 11 comments
Assignees
Labels
type:docs Documentation
Milestone

Comments

@mithun12000
Copy link

Hi team,

I don't understand how can i change default response format? currenty it shows XML but i want default API response behaviour as json

Also from doc it is not clear / not mention.

regards
Mithun Mandal

@samdark samdark added this to the 2.0 RC milestone Jun 19, 2014
@qiangxue
Copy link
Member

@mithun12000
Copy link
Author

yes i did. what i understand is it will have type define and default is xml and json format.

example in doc says that if in request format there is accept header of Accept:application/json then it will provide json output.

or

if request url has parameter as _format=json then also it will provide json format.

now i also need this optional format like default format of xml/json as a data type flexible. But i dont find a way to set default format as json if nothing specified.

i also check http://www.yiiframework.com/doc-2.0/guide-rest.html

@mithun12000
Copy link
Author

Hi i found one issue/limitation on what i am trying to achieve.

code on ContentNegotiator->negotiateContentType()

$types = $request->getAcceptableContentTypes();
        if (empty($types)) {
            $types['*/*'] = [];
        }

        foreach ($types as $type => $params) {
            if (isset($this->formats[$type])) {
                $response->format = $this->formats[$type];
                $response->acceptMimeType = $type;
                $response->acceptParams = $params;
                return;
            }
        }

and

on Request->getAcceptableContentTypes()

public function getAcceptableContentTypes()
    {
        if ($this->_contentTypes === null) {
            if (isset($_SERVER['HTTP_ACCEPT'])) {
                $this->_contentTypes = $this->parseAcceptHeader($_SERVER['HTTP_ACCEPT']);
            } else {
                $this->_contentTypes = [];
            }
        }

        return $this->_contentTypes;
    }

now browser always send Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 as header.

Now i am trying to get json in this request but Request->getAcceptableContentTypes() give application/xml as format too, so, it send output as XML.

can we have a way to modify this and set a default format priority along this this too.

regards
Mithun Mandal

@qiangxue
Copy link
Member

I don't think your request is realistic: your accept header contains xml instead of json, while you want to return json. That's not the way content negotiation is supposed to work. Also, REST API usually is not directly used by browser.

@mithun12000
Copy link
Author

Yes i understand but do you expect client will send Accept header in that case? now if it create / for Accept then what response will it provide?

@mithun12000
Copy link
Author

Also I dont know if i use Jquery to use rest API call then what Accept header browser will send?

@qiangxue
Copy link
Member

If the client does not provide accept header, then the first format listed in formats will be used.
In your case, you are providing an accept header which requests for xml but you want to return json. This is not what content negotiation should support.

You can specify headers when submitting ajax requests.

@mithun12000
Copy link
Author

In my opinion there should be a default response format. In my case i can clearly see that content negotiation not a solution which i think most of the user would like to use json. But we can still create our own class and override content negotiation.

In my case i expect default response is json. if anybody what to get other then json formal then i will give other output as well.

@qiangxue
Copy link
Member

If you do not need content negotiation, then you can remove it and explicitly set the response format as json.

The issue you described here is that the accept header says it wants xml, but you want to feed it with "json" as the default format. That's self-contradicting.

@mithun12000
Copy link
Author

well let put this in different way.

Now same scenario if i request with parameter _format=json it explicitly provide json format as i think it makes it own priority. But in my case it's not as the logic flow.

In my code if i explicitly set request parameter _format then it might work as i need. In that case it will not check for your request header. This means there is a override parameter for it. Also this parameter is configurable.

So my suggestion will be if you provide a default response format which can override the response format as you do in case of ContentNegotiator->formatParam is set and it is present in request.
If anybody set default response format then it's default response is as set if it can be override by ContentNegotiator->formatParam.
Now if user don't set default response format then current workflow is great.

I believe very small line of code will implement this small improvement which might be a nice to have feature for developer / API developer.

regards
Mithun Mandal

@qiangxue
Copy link
Member

I don't think it makes sense to add this default format. As I said if you only want to support one format and would like to ignore accept, just don't use ContentNegotiator. If you still want to support accept, then your example text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 works as expected because xml has higher preference than */*. Adding such a default format means adding confusion to the whole content negotiation concept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:docs Documentation
Projects
None yet
Development

No branches or pull requests

3 participants