It looks like this article on Ajaxifying your Site has the pieces that I need:http://www.c5tutorials.com/tutorials/ajax-ifying-your-site-part-1/....

The combination of a view (the displayed page) and controller (which can be used in an AJAX setting for responses to the view) makes sense.

The controller is loaded when the view is displayed.

Since I don't need the view, is there a way that I can load the controller permanently so that it can serve as a REST server?

I'll let you know what I come up with.

Interesting. Routing takes place only through index.php.

Whilst you are looking at it from a REST point of view from your Twillo activity, from the point of view of the C5 single pages you use to implement the REST, it is just a normal page delivery. (The C5 ajax actions are for responding within C5).

You may find this theme of interest, the example/screenshot fulfils a similar role with a C5 pages embedded within facebook. There was also some chat about it on Totally Random a couple of weeks ago.

http://www.concrete5.org/marketplace/themes/the-void/...

The other mechanism you will need is security, so that other sources cannot spoof the REST interface you build as single pages into doing anything nasty. Again, that is outside of C5, so I think it is probably up to you to look for whatever security tokens Twillo can provide to your pages and verify them in your single page code.

John --

Thanks, that's helpful for the context.

As you note, AJAX is designed for communication within C5, while REST communicates with external resources.

Your link and commentary are an excellent example for a visual interface embedded in another site.

In my situation, which is a more traditional REST interface, no interface is needed. I was trying to use the Single Page to access the controller, so that I could use C5 routing.

But, that's actually not needed. If a file is referenced on the site without interacting with index.php, Apache rather than C5 handles the request. So, in the standard C5 directory structure, I should be able to create a PHP file to receive the request and process it with the Twilio library, and then use apps in Tools to access the database. This bypasses the framework overhead of screen creation, and, as you note, security. And, defense in depth is appropriate.

I'll be working on this over the next day, so I'll report if this approach works.

Jordan -- thanks for your review, analysis and guidance.

As Jordan says, a tools file is the best way to go if you don't require a UI. It will also be the best choice from a performance standpoint. The downside is that there is no MVC coding paradigm available and thus no "controller" to help organize your code. You'll just have to keep your code organized in whatever way makes sense to you.

-Steve

you can include elements, libraries, helpers,and models quite extensively though.

C

Indeed. There's just not the convenience of a controller. Of course, one could create their own OOP library, which is probably the approach I'd take.

-Steve

Interesting point about the architecture. Twilio provides a REST library, much as C5 has several approaches to AJAX which greatly simplifies coding. The REST function probably is closest to a controller in the MVC model (though obviously not a C5 controller). At this point, I think I'll simply make dedicated functions/REST resources for each separate request, as I don't understand the commonalities well enough to class. Since I'm looking only at a handful of REST endpoints, with additional info conveyed with cookies, that probably won't be troublesome. Think big, start small...

Yes, one's design depends on whether processing POSTS or GETs/PUTs.
The controller aspect is needed to parse GETs/PUTs, as the AV formatted data is passed in the resource address. But, in a POST, the AV pairs are handled in a cookie passed, so the requirement is reduced to a parsing issue.

Shotster --

Here's an HTTP server that looks pretty finished -- it does provide an MVC architecture:http://luracast.com/products/restler/....