Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'll try to keep this question as specific as possible..

I'm about to start building an API for an upcoming project. I'm currently thinking PHP/Symfony2. It will be a farily simple HTTP-based api for CRUD on the site's models (and relationships between them).

There will also need to be a CMS for users. Traditionally when building a CMS (if it's bespoke) I'd just use some standard MVC based approach, but for this particular project I'm thinking I could build it using Ajax calls to the API that will already exist.

My question is essentially to decide which way to go, but to keep it specific I'd like to know what drawbacks there might be.

In favour of this, it should reduce duplication of controller logic, why have /api/model/save/ and /cms/model/save doing very similar things?

Currently the only two drawbacks I can think of are that:

  • It may be hard to support a wide range of browsers. For this particular scenario, this shouldn't be a problem - but who knows what might happen in the future?

  • Some parts of the site would require traditional PHP logic or an extension to the API (for any parts not part of the core API itself), for example to handle admin authentication.

Is there anything I've missed, some overwhelming reason not to take this approach?

share|improve this question

migrated from stackoverflow.com May 10 '12 at 9:02

This question came from our site for professional and enthusiast programmers.

    
Looks good so far. –  hakre May 4 '12 at 23:13
    
@MarkTrapp I wasn't exactly sure on that, or the exact distinctions between the two, but I'd go for that –  Adam May 4 '12 at 23:16

2 Answers 2

up vote 1 down vote accepted

I don't know the particulars of the project, but I think your main problem is this:

Do you trust your user with everything?
If you use AJAX, the user may alter it and call your API in an undesired way. Which, in turn, means that you have to design your API so that it's secure. That would definitely slow you down.

I'd advise you to not do it, unless it's a research example: there's too much to loose and too many ways to screw it up.

share|improve this answer
    
This would be an admin panel, with one user who would be able to do everything anyway, but I guess that could change making things complicated –  Adam May 10 '12 at 14:12

The other issue you might run into is maintaining state (you mentioned authentication) but as your system gets more complex, you might have to lean heavily on cookies to know what's happened, persist user IDs across requests etc.

I wouldn't try to discourage you from this approach, but make sure that you keep this in mind as you do your planning as it could spiral out of control if you don't have a plan for it.

share|improve this answer
    
I hadn't thought about that. I guess for simple CRUD it would be okay, but as you say, it could get messy. –  Adam May 5 '12 at 0:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.