generated schema and tests for v1.3

[BrapiCoordinatorSelby]

@martinbaste @langeipk @patrick-koenig Not sure who should review/deploy this. Do I need to add Mehmood?

• I added Collection and Schemas for BrAPI v1.3. They are not perfectly detailed, but they are pretty good and generated directly from the swagger doc. If details are missing (required fields, array lengths, etc), they should be added to the swagger doc

• I attempted to solve #30 by adding a flag indicating the origin of the test and relaxes the need for port 80 if someone is using the "Test your own" tab. There is probably a cleaner way to do this with a "TestContext" object of some kind, but I was lazy for right now.

• Github had a notification that the Jetty packages were outdated, so I updated to the recommended version. Running on my laptop, it seems like everything still works as before after a Maven clean install.

• I added an endpoint for the BrAPI versions list so that the web page and the backend are working from the same list.

Let me know if you have questions

[patrick-koenig]

Hi Pete,

first: Mehmood does not have a Github account yet and is currently not working on BRAVA.

Thank you very much for your contribution and the invested time!

I've merged your changes and updated our running BRAVA instance at http://webapps.ipk-gatersleben.de/brapivalidator/ to this latest version.

Can you tell us something about the automated creation of the collections and schema files? So how do you create the schema files based on the OpenAPI 3.0 specification files (yaml)? Did you use this Python script you proposed some months ago?

Another important question is how we deal with the several versions for the scheduled automated tests of all registered BrAPI ressources (startpage)? How to derive the version of an endpoint if no versions supplied in the /calls resource?

[BrapiCoordinatorSelby]

Can you tell us something about the automated creation of the collections and schema files? So how do you create the schema files based on the OpenAPI 3.0 specification files (yaml)? Did you use this Python script you proposed some months ago?

I wrote this python script to generate the test files: https://github.com/plantbreeding/API/blob/master/Scripts/buildJSONSchema.py

I kept it in the API repo because it references some other scripts I have written previously for manipulating the BrAPI documentation. The models in the OpenAPI 3 YAML files are already in a compatible JSON Schema format, and YAML can be directly converted to JSON.

• First, the script loads the YAML into a Python dictionary,
• then makes some small changes to each schemas as needed (allowing 'null' types for non-required fields, fixing the string 'format' key, etc),
• then links path variable names to be used by BRAVA ('searchResultsDbId' needed some special handling since it is used in multiple calls now),
• and finally turns the python dictionaries into JSON files.

I did not get a chance to add many comments to the script, so it is still a bit messy, but if you have the API repo checked out you should be able to run it yourself.

Another important question is how we deal with the several versions for the scheduled automated tests of all registered BrAPI ressources (startpage)? How to derive the version of an endpoint if no versions supplied in the /calls resource?

Yes I have put a little thought into this. The 'versions' array was added to the /calls endpoint in v1.2, so if there is no version information, I think we can assume v1.1 (I haven't heard of anyone with an active 1.0 implementation). But there is a very real possibility that some people will have servers with multiple versions present, so there will need to be some minor UI redesign and backend refactoring to be able to handle testing multiple collections against one server.

I don't have time to work on this problem right now, but there are 2 big enhancements to BRAVA I am eager to work on in the near future: The versioning issue you mentioned, and adding OAuth capability.