Hi Aapo,
Thanks for your interest.
> apitools is basically a proxy between application that is making (client) or receiving (server) API requests (in many cases ReST based APIs)?
You got it right, that's exactly what APItools is.
> Are you also thinking about gathering code to actual ReST APIs client code as well?
Your question was a bit difficult to understand. If I got it correctly, your question has a technical part and a business part. I can answer the former with confidence, but not the later.
While it would be **possible** to change APItools to do what you suggest, it was built so that it had both a "source API" on one end and a "consumer" on the other. Changing this would imply a significant amount of effort, so it would have to be justified.
Business-wise, my impression is: the company which develops APItools, 3Scale, specializes in managing APIs built by others, not in providing the means or facilitating the creation of new APIs. Investing effort in APItools makes sense as long as it is aligned with that endeavour. If we enter the realm of "API creation", then changing APItools the way you say might be considered. For now thought, I don't see it happening. Maybe in the future.
That said, you can already "create APIs with APItools"; you could choose a random endpoint (i.e. http://google.com), embed a bunch of logic into a middleware, (for example, make it dependant on the request path), and then use that as an app or api. There's even a (small) in-memory database that you could use as persistence. It would be awkward to program because you would be using APItools in a way it is not designed to work. (I must warn you that I doubt that creating such a thing would win the contest - you will have more possibilities if you create a middleware).
I hope I answered your questions!
Enrique / Kikito
