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:
The cons:
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..
Sign in to participate in this thread!
The Laravel portal for problem solving, knowledge sharing and community building.
The community