Hakuna matata!

aus http://framework.zend.com/manual/1.12/de/zend.controller.front.html

Praktisch eine Neuerfindung des Apache-ResponseHandlers ;)

Nein, das ResponseHandler-Interface definiert eine _clientseitige_ Schnittstelle, um auf _eingehende_ Antworten eines HTTP-Servers zu reagieren. Deshalb ist sie auch in dem Paket org.apache.http.client definiert.

Das lässt sich eher mit JavaScripts AJAX vergleichen:

var request = new XMLHttpRequest();  
request.open('get', '//example.com');  
request.send();  
request.addEventListener('response', function ( event ) {  
   var response = event.target.response;  
});

In JavaScript wird von XMLHttpRequest automatisch eine response-Eigenschaft erstellt, wenn die Serverantwort eintrifft. Diese response-Eigenschaft kann verschiedene Typen haben, abhängig vom ContentType der Antwort. "text/plain" führt dazu, dass die response-Eigenschaft den Typ "String" bekommt. "text/html" führt dazu, dass die Eigenschaft ein DOMDocument wird. "application/json" führt dazu, dass response ein planes JavaScript-Objekt wird.

In Java ist es ebenfalls möglich, dass Response-Objekte verschiedene Typen haben, aber weil Java statisch typisiert ist, geht das nicht so ohne weiteres wie in JavaScript. Der Typ muss irgendwo festgelegt werden, und dafür gibt es das generische Interface ResponseHandler. Das wird besser verständlich, wenn man sich die Signatur anschaut:

ResponseHandler<T>

„T“ ist hier ein Platzhalter für einen generischen Typen, man wird im späteren Programm vermutlich mehrere konkrete Typen haben, zum Beispiel ResponseHandler<DOMDocument> oder ResponseHandler<String>.

Das ResponseHandler-Interface ist nur eine sehr abstrake Bauvorschrift für mögliche Implementationen. Vor allem aber definiert es eine _clientseitige_ Schnittstelle.

Der Front Controller hingegen ist etwas, was man auf dem Server antrifft und man versteht ihn am besten einfach als Eintrittspunkt für die Webanwendung, die dann _serverseitig_ ausgeführt wird.