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

Any plans for supporting readonly marker ? #986

Open
quirell opened this issue Jul 26, 2023 · 6 comments
Open

Any plans for supporting readonly marker ? #986

quirell opened this issue Jul 26, 2023 · 6 comments
Labels
enhancement New feature or request openapi-features OpenAPI features support issues

Comments

@quirell
Copy link

quirell commented Jul 26, 2023

Description

Accordint to the specs, properites marked with readonly should not be send as part of a request body

components:
  schemas:
    Common:
      type: object
      required:
        - id
        - createdAt
        - updatedAt
      properties:
        id:
          type: string
          format: uuid
          readOnly: true
        createdAt:
          type: string
          format: date-time
          readOnly: true
        updatedAt:
          type: string
          format: date-time
          readOnly: true
    User:
      allOf:
        - $ref: '#/components/schemas/Common'
        - type: object
          required:
            - name
            - surname
          properties:
            name:
              type: string
            surname:
              type: string

but I'm getting bad request.

{
  "error_message": "operation CreateUser: decode request: decode application/json: invalid: id (field required), createdAt (field required), updatedAt (field required)"
}

Do you plan to add support for readonly in a near future ?

References

https://spec.openapis.org/oas/v3.0.3#fixed-fields-19

@quirell quirell added enhancement New feature or request openapi-features OpenAPI features support issues labels Jul 26, 2023
@ernado
Copy link
Member

ernado commented Jul 26, 2023

This will require splitting server and client structures (i.e. different structures for client request and server request in signatures), which we want to avoid.

Probably we can reconsider this on some point, because there is another feature that can lead to this split.

@quirell
Copy link
Author

quirell commented Jul 26, 2023

Got it. So for now the only option is to have that split directly in the api definition, is that right?

@quirell
Copy link
Author

quirell commented Jul 26, 2023

And to be honest, Ithink you don't need to split the structure between client and server. It would rather require generating different structure for post put and different structure for get etc.
Client and server would both the same schema but depending on the method, or rather the presence of request body in the api definition, you would use Schema and SchemaForUpdate (with readonly properties filtered out)

@ernado
Copy link
Member

ernado commented Jul 26, 2023

Oh, you are right.
I'm positive for this feature in this form.

@sonu27
Copy link

sonu27 commented Dec 14, 2023

Any updates on this @ernado ?

@timsofteng
Copy link

@ernado It would be super helpful thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request openapi-features OpenAPI features support issues
Projects
None yet
Development

No branches or pull requests

4 participants