A Journey-based Hypermedia Client
Update
I did, in fact, build a fully working client and you can read more about that on GitHub.com
~
I’m playing around with building a client for use with any REST API. The API would need to be genuinely RESTful to work and indeed writing the client code would be the starting point for API development.
I’ve got some of this working. Notice how HTTP isn’t leaked through the API, there’s no notion of verbs or URLs.
I’m worried about how to abstract ETags. This sort of stuff might make the model a little dirty, leaking some protocol concepts.
Bunches of methods could be condensed into nicely-named extensions.
BDD frameworks could easily bind to these extensions and designing APIs could be done through expressive scenarios.
Perhaps I could add some kind of neatly generalised method that populates a dictionary with the HTTP response details so that the HTTP behaviour can be verified after each step.
.ReadResponse(out Dictionary<string, object> responseData)or.ReadResponse<HttpResponseModel>(out HttpResponseModel)
I’m also interested in have the code that drives the API switched-out for code that writes the API, or the Blueprint or something. So the API is designed client-first.
Perhaps a set of BDD tests would result in a blueprint that would satisfy the tests?
