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

[Trey Darley <trey.darley@cert.be>]

Indeed, nice work, Stephen!

+1 to adding a Swagger definition as a committee note - that'll be a
huge help to future implementers.

Cheers,
Trey

On 07.02.2020 19:54:00, Bret Jordan wrote:
> 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
> >
> >
> >
> >
> >

-- 
CERT.be / Centre for Cyber Security Belgium
Mail: trey.darley@cert.be
GPG: CA5B 29E4 937E 151E 2550  6607 AE9A 7FF2 8000 0E4E
Web: https://www.cert.be
-- 
Under the authority of the Prime Minister
rue de la Loi 16/Wetstraat 16, 1000 Brussels - Belgium

Attachment: signature.asc
Description: PGP signature