usually we use the OAuth2 security schema. but public endpoints
do not have this security constraint. callbacks don't authenticate
against the called endpoint.

For reference, the warning was (one example):

> Every operation should have security defined on it or on the root level.
>
> 418 | get:
>     | ^^^
> 419 |   operationId: get-destination-key
> 420 |   summary: Ruft einen JWK des Zustelldienstes ab
>
> Warning was generated by the security-defined rule.

using npx, we can run all redocly commands without doing a global
install of redocly/cli (-g flag).

I also noticed we were using `latest` which outside of dev tests
is not recommended.

Some shorthand flags were also migrated to the long ones (--output).

Marco Holz authored 1 year ago and Jonas Gröger committed 1 year ago

Publish latest API realease as `latest`.
Publish latest commit to main as `latest-dev`

fix: inline $ref's from examples because they are not allowed according to the OpenAPI spec (bycatch from planning#1409)

The default is `false` so removing the parameter works.

See planning#501 (comment 107371)

Shahid Salim authored 1 year ago and Jonas Gröger committed 1 year ago

when a destination does not support the services requested
in a submission, it might throw an error.

this validation feature is configurable by the implementation.

Prüfung der JWE Objekte durch den Zustelldienst

See merge request !146

Michael Miera authored 2 years ago and Jonas Gröger committed 1 year ago

* When uploading attachments
* When submitting a submission/reply (data/metadata)

Faelschlicherweise-Angabe-der-Callback-URL (planning#984)

See merge request !164

fix: return 200 (not 202) for new synchronous endpoints (planning#460)

See merge request !170

The endpoints and their respective response codes

                                      before              after
    1. PUT /v1/replies/<id>/reject -> 202                 200
    2. PUT /v1/replies/<id>/accept -> 202                 200
    3. PUT /v1/replies/<id>	       -> 202                 200
    4. PUT /v1/submission/<id>     -> 202                 202

returned a 202 in the positive case. This doesen't make sense since they're
synchronous requests and should return 200. For the not yet released new
endpoints 1, 2 and 3 we can still change that without breaking any kind of API
compatability.

For endpoint 4, we have to keep it at 202 for API compatability but add a marker
once v2 is considered.

Remove bidirectional flag and case state from api (planning#506, planning#511)

See merge request !169