All responses are returing objects

[ryanhungate]

Hey, brand new to the package... and I cant get it to return a view file... the controller even extends the standard Laravel Controller... but as soon as I implement the API Classes, it automatically hijacks the response and returns as json. Any clues on this? I was under the impression that only controllers that extended the Api Controller would follow that logic.

[jasonlewis]

Going to need some more details on your setup. Only routes that are registered within the Route::api group should be returning JSON responses. All other routes outside these groups should remain untouched.

[ryanhungate]

well it really seems like as soon as I load the service provider, my
controller only returns JSON responses, even if I remove the alias extend
the natives Laravel controller
On Apr 19, 2014 8:22 AM, "Jason Lewis" notifications@github.com wrote:

Going to need some more details on your setup. Only routes that are
registered within the Route::api group should be returning JSON
responses. All other routes outside these groups should remain untouched.

Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-40872088
.

[jasonlewis]

I can't seem to recreate this. You're running the latest dev-master?

Can you paste your routes, your app/config/app.php and an example controller?

[ryanhungate]

thanks for the quick help but I'm actually not at the computer right now.
I'll try to do this later today.

this really was a basic setup for just a few routes on a brand new
install...
On Apr 19, 2014 8:42 AM, "Jason Lewis" notifications@github.com wrote:

I can't seem to recreate this. You're running the latest dev-master?

Can you paste your routes, your app/config/app.php and an example
controller?

Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-40872583
.

[ryanhungate]

Hey Jason, I see that the minute I add an API route, and try the default laravel hello view - closure OR class... line 136 on the Router file is returning true, but if you dont register an API route, it works fine... $this->requestTargettingApi($request) bit. That seems to look at the collection, and see if there is a match, and the last elseif returns true which i think causes this problem.

[jasonlewis]

Okay I'm just on my way home now to look into this. What Laravel version?
On 20 Apr 2014 09:00, "Ryan Hungate" notifications@github.com wrote:

Hey Jason, I see that the minute I add an API route, and try the default
laravel hello view - closure OR class... line 136 on the Router file is
returning true, but if you dont register an API route, it works fine...
$this->requestTargettingApi($request) bit. That seems to look at the
collection, and see if there is a match, and the last elseif returns true
which i think causes this problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-40882966
.

[ryanhungate]

4.1.27 - basically the latest composer pull.

I can see that on line 63 of the ApiCollection in the last elseif - seems to validate that route for the API to match correctly, but it also matches against a typical return View::make('my_crap'), which needs to be fixed somehow. ( dont worry about this, its not in production ) and Im leavin again... but hopefully it can be fixed over the next few days, because I was hoping to rewrite a current app using this, and the newest L4 version above.

Thanks dude.

[jasonlewis]

Still unable to recreate. I'm running a clean install of 4.1.28 and this is all I've added to routes:

Route::api(['version' => 'v1', 'prefix' => 'api'], function()
{
    Route::get('/', function()
    {
        return ['example' => 'json'];
    });
});

Route::get('/', function()
{
    return View::make('hello');
});

Plus added the service provider. I can browse the default route fine and see the view. Then I can navigate to /api and see my JSON response.

In regards to line 63, that's just checking the current API collection to see if neither a domain or prefix was set, if that's the case then it's going to match. Generally you'll always be using either a domain or prefix though. If you're not, you should be.

[ryanhungate]

Hmm, well ill repull again and give that a try... no clue why. Thanks again
On Apr 19, 2014 5:03 PM, "Jason Lewis" notifications@github.com wrote:

Still unable to recreate. I'm running a clean install of 4.1.28 and this
is all I've added to routes:

Route::api(['version' => 'v1', 'prefix' => 'api'], function(){
Route::get('/', function()
{
return ['example' => 'json'];
});});
Route::get('/', function(){
return View::make('hello');});

Plus added the service provider. I can browse the default route fine and
see the view. Then I can navigate to /api and see my JSON response.

Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-40884069
.

[ryanhungate]

Hey, its official... the culprit was the fact I did not specify the 'prefix' in the api constructor. it was as simple as that - meaning the package didnt automatically assign an 'api' value for the prefix... so I would suggest that you write that in the docs, or use a default prefix if none was specified. It would actually make more sense to set that in the main config as well, to avoid having to specify that in every api grouping... now that I know, im off to the races. :)

EDIT: Actually maybe I would like to explore a little bit with the 'versions' and the 'prefix' settings as to how and why they may be used effectively.

[jasonlewis]

Yeah I guess I should make a default prefix and domain configuration options. They will be set to nothing by default as some APIs may not use a prefix or domain. Really Route::api is just Route::group with a little bit more logic, so the same rules apply. If you have two routes that will both match the request then you're going to have a bad time. Remember, first in, first out. 😄

[jasonlewis]

Recent push has implemented configuration options for prefix and domain. These will be used if you don't specify them in the API group. By default they're not set.