Proper way to provide REST service alongside typical web content service

I'm trying to figure out the best way to make access to most of my backend data available through a REST api so that I can take advantage of dynamic queries on the client side. However, I also want to serve up normal html from the same site. Being a noob at phalcon and web development in general, I'm not quite sure what the proper way is to organize these two services.

In order to achieve this, first I tried to have a single controller which would handle both. It seemed that there would be conflict with some of the method naming ( i.e. deleteAction() would mean two different things dependent on if it was a DELETE request or a GET with an action of delete ) and I wasn't sure how I would be able to determine which was the proper scenario. Then I started down the path of having an 'api' folder under /app/controllers/ -> /app/controllers/api where all of my REST controllers will reside, which led to a routing issue which I have yet to figure out. So then I explored the module option, but then decided before I went too far to ask the forum on what the best practice is for this - as I'm pretty sure it is a common scenario.

With that said, how should I tackle this? 1) Split the web application into two modules - an API module and a typical html content module? 2) Peform special routing which knows that when the url starts with './api/:controller/...' it knows to look up the controller in the corresponding 'api' folder? 3) Have a single controller to serve up both? 4) None of the above

Thanks in advance.

edited Jul '14

I am building something similar.

Personally, i have setup the REST service to be on a api.domain.com and in my webserver point to the boostrap file for the rest service. The global domain just points to the frontend bootstrap.

As i am a Phalconeer in learning, just started 2-3 days ago. These are the two main resources i used for the rest webservice:

These were used as pointers, i haven't used the code it self but it gave me a good idea on how to start.

I think the best solution would be 2 modules. Never having used modules myself though, I can't give much advice on the topic.

REST apis are generally fairly simple, so might you be able to just make one big API controller?

Thanks folks.

Having a sub-domain for REST services sounds interesting. Though, I'm wondering if there is a way to merge into a single 'service' but just distinguish on whether or not the url has www.mydomain.com/api - rather than the api component being part of the domain descriptor. Either way, having a sub-domain would certainly separate the concerns.

With regards to one big API controller, I would like to avoid that in order to keep things as cohesive as possible since I have quite a few tables, many of which aren't related. In fact, I'm imagining that I'd probably have two controllers with identical naming for each database table - one which handles serving up views with data, and the other which just handles the REST of the stuff.

So, I think it really comes down to where you split your REST stuff from your view/content delivery stuff: 1) At the domain level 2) At the module level 3) At a routing level ( route to different controllers based on request ) 4) At the method level in a single controller 5) At the logic level in a single method in a single controller

Personally, I'd prefer to be at 2/3 - but I'm not sure if I have good justification for wanting to be there.