I need to write a simple API for a project I'm working on. This API will be used internally to perform some server side actions that were triggered by AJAX calls.

To make things easier for me, I thought of using the Chain-of-Command/Responsibility pattern.

Here are more details about what I want to do:

I am creating a "dashboard" where admins of my app will be able to update information (meta data) about items stored in a database.

To make things easy and simple for the admins, I chose to use AJAX. So, if an admin wants to delete an item, (s)he clicks on the "delete button". A POST request is then sent to edit.php page with all the information needed to perform the deletion (action : delete, element : link, id : xx ...). Where action, element and of course id can change.

This is why I opted for a mini-API that will, depending on the action and the element data, call a different function from a different class.

Now, to implement the API, I decided to use Chain-of-Responsibility design pattern. Why? Because I can easily add, delete or update classes without having to modify the API itself.

Is the Chain of Responsibility design pattern good fit for my case?


3 Answers 3


The idea of the chain-of-command pattern is to build a chain of handlers and pass a command along this chain until one of the handlers handles the command. This behavior is typically found in event processing, where, say, a click event from a UI button bubbles up the hierarchy of UI elements till it reaches an element that has a respective handler attached. This handler can then decided whether it handles the command -- effectively ending the event processing -- or not -- in which case the event is propagated further along the chain.

Let's now assume we use that pattern for you web API. What you describe sounds like a classical CRUD(L) interface to me, where your actions are (a subset of) create, read, update, and delete. You say you have delete requests and I'm assume that you want some kind of update requests, too. Let's assume further that you wrote respective handlers hupd and hdel for these kinds requests. Following the chain-of-command pattern, you then build the chain [hupd,hdel] to handle requests to your API. What happens is that every update request passed into the chain gets immediately handled by hupd, while every delete request is rejected by hupd and passed along to hdel, which handles it. This behavior shows a fixed mapping between actions and handlers that actually makes the chain unnecessary. (In fact, the chain even lowers your system's performance, because of the check and the passing along of every delete request). Why does this happen? Because there are no two handlers responsible for different subsets of requests with the same action type. What you really want to have here is a direct mapping ["update" => hupd, "delete" => hdel] and a dispatcher that takes respective requests and passes them directly to the respective handler. Such a design can still be extendible with regard to new actions, if there is a dynamic registry holding the mapping.

Now you could say, that you want to have different handlers for, say, the deletion of elements of type A and B. What gives you handlers for subsets of requests with the same action type. But once again, you have a direct and fixed mapping between the handlers and the element type, i.e., you can repeatedly dispatch requests based on the target element type. This gives you a two-level dispatch, where with a chain-of-command you would pass the request through number-of-actions times number-of-element-types handlers, in the worst case.

Conclusion: I would not recommend the chain-of-command pattern to implement this kind of API. For the pattern to have value, you need a scenario where you want to dynamically add and remove handlers and where the condition of when a handler actually handles an event is not expressible by a simple mapping from constants.

  • Thanks for the answer, using a dispatcher is a good idea. But the problem with this implementation is that once I needed to add another type of elements or another "action", I'll have to alter the dispatcher. In a CoR pattern, however, all I need to do is to add a new "command". You mentioned some performance decrease because of the CoR pattern, but passing a request through a "number-of-actions times number-of-element-types handlers"-series of ifs and/or switchs isn't that bad. right ? Does this small amount of optimization justify sacrificing the flexibility of CoR ?
    – ahmed
    Oct 3, 2013 at 18:47
  • 1
    You don't need to alter the dispatcher to add a new actions. The only thing you need is a map from action to handler(type). When requests come, the dispatcher checks this map for the handler, using the requested action. The map can, for example, be managed in a configuration file, by dependency injection, or via dynamic inclusion of handler files (what requires you to keep all <handler>.php files in a certain location). Anyways, given the small number of actions you probably have, the performance overhead of CoR should be negligible.
    – Sven Amann
    Oct 4, 2013 at 14:10

I do not recommend using a single method to handle all the request operations. Ideally you should use DELETE to handle delete operations, thus helping you to have an API which exactly tells what the API is all about and POST, GET and so on.

I would suggest you to start defining your API's first as a starting point.

  1. Deleting an item in the dashboard -> http://domain.com/dashboard/itemId - Delete Operation
  2. Refreshing an item -> http://domain.com/dashboard/itemId - Get operation

See, the API is self explanatory, and would give a clear picture of what you want to do as well as help in maintenance.

In your controller you can detect the operation and then call respective services for each operation to take an action. COR may not be a good option, as it does not fit in here.

  • Using a RESTful API is a very good idea. I think it's time for me to learn more about it. Thanks :)
    – ahmed
    Oct 8, 2013 at 21:47

First of all, note that the question is misspelled, for the chain of command pattern is not related to the public API, but to its internal, server-side implementation.

That said, the chain of command pattern suits well your needs. As the API is extended with new actions and/or elements, so new handlers can be added to the chain to implement new behaviour, without modifying the existing ones.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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