Re: TAXII-Server 2.1 spec build: Java/Kotlin with OpenAPI/Swagger/ReDoc

[Stephen Russett <sr@ctin.us>]

Hey everyone

some updates on the TAXII-Server build: https://github.com/StephenOTT/TAXII-Server

1. MIT License added.
2. Rapidoc swagger viewer has been added (You can use this UI to talk to the taxii-server as a client).
3. Swagger-ui viewer has been added. (You can use this UI to talk to the taxii-server as a client)
4. Full documentation of all resources, endpoints, query params, path params, and errors has been added into the swagger generation.
5. Providers receive full request information and control response body and header response data.
6. Validation of Taxii Media Types for Accept and Content type has been added.  Configurable to control optional and required headers.
7. Security with Basic Auth has been added to all routes.  You can control auth with a Security Provider override and connect this to any user data source.
8. Proper field naming matching the spec has been updated.
9. Swagger File yml updates with lots of Schema controls (default server values, enum client values, required props, etc)
10. many fixes and spec quality control checks!

Enjoy!

From: Stephen Russett <sr@ctin.us>
Reply: Stephen Russett <sr@ctin.us>
Date: February 7, 2020 at 5:11:52 PM
To: cti@lists.oasis-open.org <cti@lists.oasis-open.org>, cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org>
Subject:  TAXII-Server 2.1 spec build: Java/Kotlin with OpenAPI/Swagger/ReDoc

Hey everyone

I just created a TAXII-Server for 2.1 at https://github.com/StephenOTT/TAXII-Server.

This build is designed to be a generic implementation that provides the API controls, but routes all requires to âprovidersâ that do the actual handling/logic.  See the Readme for a diagram explaining the setup.  In short it lets you route TAXII to a system like kafka or another endpoint, so that those backing systems do not need to understand TAXII or even produce STIX.

This server comes with a OpenAPI/Swagger file that Client APIs can consume, so devs can generate client API stubs for their code, and there is also a ReDoc viewer for the swagger file.  Check out the Readme for screenshots and instructions.

The build is in Kotlin, so you can download the ready to use jar from the releases, or build it locally and run the jar or dockerfile.

This project was put together as part of the preparation for STIX/TAXII interop, so that devs preparing their implementations have a reference build to work from and have a Client API swagger file to generate their stubs from.

It is still a WIP but all endpoints, and resources are setup with proper responses, and error handling.  See the issues for the task I am still working on.

A lessoned learned so far from converting the spec into a implementation and a swagger file has been that the spec is currently a mix of âImplementation text and internal spec rulesâ.  They are mixed up in various places throughout the spec, and not consistent.  It would be great if we could update the text in the spec so it has copy-and-pastable sentences that are the âshort textâ that someone would copy into something like a swagger file, and then the ~second paragraph is the internal spec docs/rules.  Section 3.7 of the spec that shows the description of the Envelop properties is a good example of impl descriptions and internal spec notes.

If people have some time to donate to copy-and-paste from the spec into the code, so we can complete the swagger file with all relevant implementation details/reference docs, we could then move this data back into the spec at a later date, when the implementation instructions/swagger file is considered âcompleteâ.

As always, feedback and contribution is welcomed!

Have a great weekend.

Stephen