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

[Bret Jordan <bret.jordan@broadcom.com>]

Stephen,

This is fantastic. Well done.ÂÂ

I also really like the idea of tweaking the text around so that things like a swagger file can easily be created. I am also very supportive of us hosting and releasing a swagger file as an official committee note or other committee documents.ÂÂ

Once again, well done. Thanks for doing all this.Â

Bret

Thanks,

Bret

PGP Fingerprint:Â63B4 FC53 680A 6B7D 1447 ÂF2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Fri, Feb 7, 2020 at 3:11 PM Stephen Russett <sr@ctin.us> wrote:

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