But before drilling the progressive interface an introduction to the closure “ingredient” is needed.

By changing the API to an inner closure, only one overload of the .Write() operation is needed. Because of its nature, this type of APIs have to revert to using delegates. How about a member of the Action<T> family? Not so much, as we need to return something. So a member of the Func<T> family will be. A glimpse of how things look like so far:

IEnd will be the interface that will allow the user of the API to know where we to stop. Once we have a member that returns it, we might be done writing.
Since all urls need a language to be written, makes sense that the IStart implements a method that receives a language so that we can chain the different areas from there.

A new member of the family, the IArea will have to provide one method for each area available. In our case, methods for the content, entity and complex areas. Note how a member that returns an IEnd is implemented, meaning that writing that url is done:

Time to be closing the interface with the content are. One can chose to end with a property instead of a method, but that is just a matter of taste:

Time for the entity area:

The last bit is the implementation of the complex area, which, being complex is a bit more interesting because we have several places when we can stop writing: after providing an S1, for instance, which can be modeled implementing IEnd in every “end point” interface. Besides we give the user of the API the ability to chain several values for the complex S2 collection:

 

It feels good and useful. One problem though, we are nowhere near done as all we have so far is a bunch of interfaces. They will need to be implemented, as well as the Write() method. But that will be the subject of the next pot of the series.