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 am using PHP Codeigniter MVC design pattern

and I had this project with some sort of specific business processes

In my application I will be dealing with 2 existing REST APIs:

  1. Google
  2. Trello

I came up with idea to create REST API to act as Business Logic Layer (BBL)

that in turns access my models directly to fetch needed data to formulate business rules

and controller with communicate with BLL with REST client, enter image description here

Is that bad approach for performance ?

Is it better to create 2 layers of Models one as Data Access Layer (DAL) and one as Business Logic Layer (BLL)

share|improve this question
    
REST is used for the interactions between components. It is not an architectural layer! However, it could be used in a layered architecture. –  Dave Hillier Mar 16 '13 at 1:04
    
The semantics of the question are wrong. It can not be used as an architectual layer, but it could be used as an interface to a layer. –  Dave Hillier Mar 16 '13 at 1:08

2 Answers 2

up vote 9 down vote accepted

The problem I see with your approach is that you are building a REST API for only one consumer, your controllers, and that's overkill. Don't just add a layer just to pass data from one layer to another, there's no point, you'll be creating work for yourself for no additional benefit.

One (quick) way to make your API useful would be if it was the only endpoint your controllers (i.e. your application) ever needs. Consider this:

enter image description here

Suddenly your REST API has a purpose, and that is to provide a unified interface to your various data providers. Your application doesn't need to know about the Google or the Trello API, or any other data provider you might use in the future, it just needs to know about your REST API.

This design, albeit slightly more useful, is still overkill if your application is the only consumer. The whole point of building a REST API is to expose a publicly available interface for your applications to share. And the key here is exposure, your REST API will be available to the world and therefore it must be secure. API authentication and authorization are no simple tasks, if only one application uses your API, why go through all the trouble? Unless of course you want to experiment and learn. If that's the case, by all means go for it.

In any case, performance shouldn't be an issue. You'd be adding an extra layer, so obviously there will be some overhead, but whether that overhead will be significant or not depends entirely on your implementation. If your REST API is the single endpoint, then it will probably be a good idea to also be the one place where caching happens. And not just server side caching, a REST API makes browser caching a bit more easier to exploit, and if you get it right, the overall performance of your application may increase, comparing to a non REST approach.

tl;dr: Don't build stuff that don't have an actual purpose (unless you're learning).

share|improve this answer
    
Thank you @Yannis Rizos for your reply I liked your architecture and i think i m goin for it but a small question, what you meant by "Application" is a whole MVC or only VC (View and controlller), as I think controllers will have a lot of code handling like validation, XHR...etc i dont wanna over kill it with REST calls even if it will be few of them and rest of BLL will take care of the rest –  Ahmed Samy Mar 16 '13 at 9:14
    
and is it good to connect another REST Api from my REST API ? –  Ahmed Samy Mar 16 '13 at 12:50
1  
@AhmedSamy Your REST API is essentially a different application, it can get data from anywhere it wants, including your models and other APIs. You'll need to build RESTful controllers for it, and perhaps even views. Your main application can call your REST API either through its controllers or through its views (via Javascript). –  Yannis Rizos Mar 16 '13 at 13:23

Based on your drawing, it seems like there should be a model called by your controller that deals with talking to Google, getting the results back, formatting it for your app, and then that is sent to controller ready to go. In other words all the google specific details would be in that model. same for trello. that way if you need to add more apis to consume, you have kept everything nice and separate.

this is a small detail - but remember in your overall app design - you have to account for possible delays in sending / getting the information from the api server to your server. in other words make sure your app doesnt completely hang up if the trello server is slow or down.

Apis have to be concerned with security but they don't necessarily have to be 'public'. many apis are business to business with nothing public.

i've read most of this book - its short, still early release, and not enough examples - but its very current, its all php, and the author is actively creating and teaching about apis. http://shop.oreilly.com/product/0636920028291.do

the author has php rest api related posts on her blog. http://www.lornajane.net/blog

and be sure and read the comments for the api posts! seriously it will give you very valuable perspective.

Suggest that you google "hypermedia" and api. you might not want to use it, but it will show you some other techniques for api creation.

I've just joined programmers - i would upvote this question if i could! most businesses will not be able to create entirely new applications for consuming or publishing apis. so coming up with best practices for integrating apis into existing mvc frameworks -- this is really important.

share|improve this answer

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.