Prototyping the web API

Categories Development


Since my ideal web application model includes a decoupled web client and since I favor an interface-first approach while prototyping and development, I always try to code the user interface as decoupled as I can from the web tier.

At first, I’ve tried developing the web components (HTML, JS, AJAX and all) as standalone packages, not integrated in the user interface. Well, that works… the only problem is that it leads to hacks and to a “one API per user interface” approach, which I really hate.

Seeing this, I started to develop my web interfaces disconnected from the web-tier, by mocking the data services using:

  • simple files served by a vanilla Apache instance;
  • which evolved into a ruby environment running Sinatra;
  • which ultimately turned into a node-js dynamic application…. which frankly feels like I’m shaving yaks using rugged stones (mostly because it’s just a bunch of JSON configuration files that you have to edit manually) so I’m now going to replace it with something new – something usable that can really cut my effort.

The idea is still evolving but what I want the final product to do is:

  • serve static files (for web client files and frameworks);
  • allow the user to actually build a web client application with no backend;
  • let the user define dynamic answers to HTTP requests in a simple way, defining an API of all the service calls that the client will need to fully function;
  • let the user export the defined API in a readable format;
  • let the user save his work in a human-readable format that can be stored in VCS.


While building this thing I’ll have to build a sample / proof of concept app just to test the beast.

2 thoughts on “Prototyping the web API

Leave a Reply

Your email address will not be published. Required fields are marked *