Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise Descriptions When OSCAL Content Sent by Client #91

Closed
2 of 3 tasks
Tracked by #82
brian-comply0 opened this issue Mar 25, 2024 · 2 comments
Closed
2 of 3 tasks
Tracked by #82

Revise Descriptions When OSCAL Content Sent by Client #91

brian-comply0 opened this issue Mar 25, 2024 · 2 comments
Assignees

Comments

@brian-comply0
Copy link
Contributor

brian-comply0 commented Mar 25, 2024

Description

As a developer issuing OSCAL REST API calls to send OSCAL content, I need to understand how to identify the OSCAL format I sending.

Acceptance Criteria

  • For each model, the description for the following endpoints is updated as defined below
    • POST /[model-name]
    • PUT /[model-name]/{Identifier}

Description Content

The current description should be maintained for each of the two endpoints, with the following added to that content:

The client must include the `Content-type` HTML header and set it to one of the following:
- `application/json` when sending an OSCAL file in JSON format;
- `application/xml` when sending an OSCAL file in XML format; or
- `application/yaml` when sending an OSCAL file in YAML format.

The implementation _must_ accept all three OSCAL formats. OSCAL content sent to the server in any one of the three formats _must_ be made available in all three formats for the relevant GET method/endpoint combinations.

@brian-comply0
Copy link
Contributor Author

brian-comply0 commented Apr 5, 2024

@mpemy This has been addressed for the POST methods in PR #72 as required; however, this has not yet been addressed for PUT /[model-name]/{Identifier}
Moving to sprint 67.

@brian-comply0
Copy link
Contributor Author

POST and PUT have now both been addressed in PR #72.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants