I KEEP six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
In Prototyping the web API I started describing an idea to build a tool that can be used to try out/prototype web APIs before actually building a back-end implementation, helping a team to describe a clear and strict HTTP API, as well as allowing them to build and test client code without having written one line of server-side code.
This post is taking those ideas further, trying to crystallize the concept, objectives, goals and my overall expectations of this tool.
Based on my previous attempts at crudely building a harness for my web development habits, I’ve outlined a sort of a wishlist.
Apis, as I’ve so naively chosen to name this tool will be a part of my typical development stack and must:
- Have a pleasant, easy to use interface where I can define the desired HTTP API, including endpoints, request and response configuration that I can export as a well-structured definition document;
- Allow me to save the definition in a human readable and human editable format that can also be saved, compared and merged in a VCS;
- Allow me to define standard responses for each API endpoint based on the request configuration so I can test the API, build a proof-of-concept API and even build a whole user interface decoupled from back-end services;
- Be standalone and packaged in an easy-to-use installer so I can send it to my fellow developers that can load the API definition from VCS and work on it.
That’s about it. If it seems pretty simple, it’s because most useful things are, and should be…. simple.
This is a simple one:
- I like a well-defined, clear and strict web API in my projects. I want others to want one too;
- I like to prototype a lot. I want to be able to quickly prototype a web interface without having to set up a web server or –hell no– a full development environment. I want to make it easier for others to prototype;
- I want to test my decoupled web clients in a clean, well-known state and I want my server-side code to have no idea who they’re talking to.
This is a simple one too:
- Not like I did before. I want a desktop app, not a whole bunch of code, glue and configuration files;
- I want to build it clean, so I can easily extend it. I don’t really care about other operating systems than Windows so I’ll build a Windows desktop app;
- No bloody way I am building it in some scripting language again and I code Java professionally so I don’t want to do it in my spare time. Plus, I really like C#, the .Net stack and WPF;
- I’ll build it in my own time, build it right, and build it for myself (for a change).
So, Windows, C#, WPF, VS Express and a whole lot of will power it is!
I’ll build it iteratively and story-based. I won’t say agile because well, for an agile process treating communication and people problems… let’s say that you need a minimum of two people for hate or love.
When, Where and Who?
There’s no better time than now and no better place than wherever I am. The Buddhists say it well “Wherever I am, I am home, I am now, I am free”.
I’ll start building it alone. I know it’s not a good idea to work alone, that in programming, one is the loneliest number but later on, if it catches on, I’ll try to get some other people on board.
I’ll host everything on gp… it’s been lonely since the migration to WordPress.
That’s it for now. I was storing this in my brain, which is stupid… that’s why I have a blog.