This gist demonstrates a DSL which could be used to describe a Hydra API (could be generalised to fit any hypermedia API as long as the lingo is made not Hydra-specific)
The core terminology of an API is hidden in the API Documentation. I propose a tool which takes the RDF contents of said documentation and produces a xtext DSL definition which includes all the API-specific bits: classes, properties, operations.
api-dsl-gen \
--api http://flick-mis-traem.li/apidoc.jsonld \
--header Authorization: Bearer jwt-token \
--out flick-mis-traemli-authenticated.api
Note the JWT. I expect one could also produce multiple such DSL flavor if the API Documentation was dynamic in nature. Each could be used for a subset of tests which depend on the caller's authorizations.
This is step could be optional, at which point any API terms would not be available for IDE suggestions but the general syntax proposed should still allow to exercise an API using links and forms provided by hand.
Check the other files for detaild examples of how the test "scenarios" could be structured
I recognize that there are two possible ways to construct the scenarios:
- Nesting subsequent steps
- Hoisting steps to top level
I think that both approaches can be supported and complement each other.
When instructions to follow links or invoke operations are nested, they should be attempted unconditionally. This way unsafe operation, such as DELETE
can be exercised within a well-defined execution path.
Otherwise, possible interactions are selected from those defined at top level. For example, the first time a resource of type fmt:ProblemReport
is encountered, its operations and links are looked up at top level and executed. It's important that each such top-level path is only ever ran once.