At the 3rd Party Dev State of the Union at EVE Fanfest 2016 earlier this year, CCP FoxFour drew my attention to a limitation of the current approach used by crestmatic to generate CREST documentation: it only discovers resources always reachable from the API root from the perspective of the authorised character at generation time. As CREST now includes APIs for transient resources like fleets the entire API isn’t reachable for documentation from a nightly run using the credentials of a character not in a fleet.
There are a couple of ways to fix this. At the API level OPTIONS responses could refer to linked representations that can exist. An alternative is to extend crestexplorerjs with OPTIONS metadata to make it expose live documentation about reachable resources.
At a recent hackathon I took the second approach. crestexplorer now makes OPTIONS requests to each resource it requests and uses crestschema and data urls to generate downloadable JSON schema descriptions for each of the representations available for a resource. It also hyperlinks to the alternative representations so now all representations of all reachable resources are available in crestschema and the human readable descriptions of each field are added to the rendered resource as hovertext.
Now documentation for any valid CREST resource live by specifying the URI for the resource as the crestexplorer hash fragment. Even when the resources are transient documentation is available for resources while they exist.
A year ago I gave a talk at EVE Vegas about building RESTful CREST applications. My #1 recommendation was to specify representations in requests, but that’s hard to do when there is little documentation on which representations are available and what they contain.
Fortunately CREST is self describing: send …read more
Free Tests For Everyone!
Modern software development is sometimes colourfully described as being similar to firing tracer bullets at a target. Rather than spending time doing a lot of research, design and specification up front, the smallest, simplest version of the software is built and the feedback gathered from its use is used to …read more
Investing In Testing
Last year I was talking to an engineer at Droidcon London who was working on an Android app with 100% test coverage. I immediately asked whether he thought 100% test coverage was worthwhile: many software engineering teams strive to achieve 100% test coverage, but few succeed because it’s an …read more