não quero escrever controllers

service.java

package org.javace.oportunidades;

/* pra que? */
import static br.com.caelum.vraptor.view.Results.json;

import java.util.ArrayList;
import java.util.List;

import org.hibernate.Session;
/* pra que? */
import br.com.caelum.vraptor.Consumes;
import br.com.caelum.vraptor.Post;
import br.com.caelum.vraptor.Resource;
import br.com.caelum.vraptor.Result;

/* pra que? */
@Resource
public class IndicarOportunidade {

	private Session session;
        /* pra que? */
	private final Result result;
	private ProdutosJaIndicados produtosJaIndicados;
	
	public IndicarOportunidade(ProdutosJaIndicados produtosJaIndicados, Session session, /* pra que? */ Result result) {
		this.produtosJaIndicados = produtosJaIndicados;
		this.session = session;
                /* pra que? */
		this.result = result;
	}

       /* pra que? */
	@Post
	@Consumes
	public List<Oportunidade> comoColaborador(Indicacao indicacao) {
		List<Oportunidade> oportunidades = new ArrayList<Oportunidade>();
		// gera essa lista, mas...
                /* pra que? */
		this.result.use(json()).withoutRoot().from(oportunidades).serialize();
		return oportunidades;
	}

}

Num caso simples desses o Result é uma coisa desnecessária, porque o framework Poderia simplesmente ter um default em algum lugar (uma configuração geral onde você poderia dizer que por padrão tudo é serializado por json).

Já a marcar os métodos eu acho que é uma coisa absurdamente necessária. Se você mete um método privado aí no seu controller e ele faz alguma coisa que só deveria acontecer dentro de uma action pública e alguém consegue chamar to lado de fora você se lasca lindamente. Métodos que são públicos pra ser chamados de fora devem estar definidos como tal pra evitar falhas do programador ao exportar coisas que não deveriam ser exportadas.

Imagine que eu quero gerar um WADL dos meus controllers, se não tem marcação, ele exporta tudo? Mas quem disse que eu quero exportar tudo?

Essa idéia de que temos que ignorar o HTTP levou a merdas surreais como SOAP, não podemos ignorar o protocolo, a forma como ele trabalha e a forma que as aplicações devem ser escritas em cima dele. Eu não usaria um framework que tentasse esconder tudo da comunicação pra mim, é perda de tempo e vai levar a elefantes brancos e difíceis de serem customizados como JavaServer Faces.

Bacana a discussão.
Nunca gostei dessa idéia de misturar responsabilidades em um controller. Acredito que a unica 'função' dele é exatamente repassar o conteúdo do modelo para a view/presenter e, principalmente, tratar a requisição/resposta, com o tipo de dado correto e com os cabeçalhos bem definidos.

A um tempo atrás, aqui na empresa, procuravamos uma solução que nos agradasse em termos de controllers simples e diretos. Infelizmente, não localizamos alternativas viáveis. Ou seja, tivemos que 'reinventar' a roda.

Minha solução (que não foi em Java), seria BEM +- assim:
https://gist.github.com/2875251