The ideal solution is to code your api in separate controller in the same applicatio (possibly extending an ApiBaseController?) Something like ControllerX does functionality X, and ApiControllerX does X the API way.

The ideal situation is when ControllerX call the Api route, parse it and display in the view. This way when you break your api, you are aware of it.

I'll edit this post later to give a gist about how it can be implemented in laravel in an elegant way (if I manage to find it)

This is how I am doing it @atrakeur, I have different controllers for the API and a Route::group() that listens to api.myapp.com.

But I am thinking about error handling ( default Error Handling must be bypassed in order to return json with some kind of msg) changes to the schema that may create changes to the models ( API access the same models as the basic app) that API doesn't care. Also isn't a problem that you force basic app and API to be hosted in the same server?

I am thinking. Is it really a good idea to have the same base? Are the pros more than the cons?

Hello again !

I've just posted my code as a gist. You can find it here:

https://gist.github.com/atrakeur/2801c42d9ff51e42d0a2

The code is commented but feel free to ask me if you have trouble getting it right.

As you can see in my implementation, the elegant syntax (in pure laravel style) make it possible to handle returning controller exceptions as json responce seamlessy. So the "default error handling" as you call it isn't really a problem.

About the models, I recommends keeping the same model codebase for both api and frontend. This way less code is duplicated between both parts.

About the multiple servers things, I have to ask about the goal of your api. If it is used to access the same data as the main application, you have to access the same database server after all.

By the way, even if you do a single app, and really want to separate servers, you can still redirect api.xxx.com to the second server running the exact same application as the primary server (one codebase). Laravel routing should handle the rest allmost out of the box. (may need some minor tweaks with apache config)

If the API doesn't care about something that is needed to the main app, so there is no problem. Some extra methods doesn't hurt, and they are ready in case your API need them one day.

To summarize: The pros:

• Same base = code shared between both parts
• code shared = less code to write/debug/upgrade
• Using your own API in your frontend app: less code duplicated, and when you break the API, your own code break before client's code do.
• if it's the same functionnality, why separate after all? you really want to write 2x the same functionnality?

The cons:

• Less separation (is it really a cons?)
• The server separation thing (but there is a workaround on this one)
• If the api and app do really different things (and can exist without each other), there is no point doing it as a single app (unecessary coupling)

Hi,

Here is a RESTful API starter I've been working on. It includes convenient way to return error messages. https://github.com/merlosy/laravel-restful-api-starter Feedback is great!

Hope it can help..

You should also take a look at Dingo: https://github.com/dingo/api