We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Beginners

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.



1.5k
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.



125.8k

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?



775

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.