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

Read-only attributes in model definition #884

Closed
thegcat opened this Issue Jan 30, 2015 · 7 comments

Comments

Projects
None yet
7 participants
@thegcat

thegcat commented Jan 30, 2015

I have swagger models defined for some of the things our API can take or give in a request, but the attributes between both are not always the same. In the following example, the id cannot be set from the API:

  "models": {
    "Cart": {
      "id": "Cart",
      "required": null,
      "properties": {
        "id": {
          "type": "integer",
          "description": "Cart ID",
          "readOnly": true
        }
      }
    }
  }

I'd though adding readOnly to the id property would remove it from the Model and Model Schema in the "Parameters" section of a request, i.e. in the part where it is used for writing, but this seems to not be the case.

Did I understand that option wrong?

@thegcat

This comment has been minimized.

Show comment
Hide comment
@thegcat

thegcat Jan 30, 2015

(I have Swagger UI version 2.1.0-alpha.7)

thegcat commented Jan 30, 2015

(I have Swagger UI version 2.1.0-alpha.7)

@webron

This comment has been minimized.

Show comment
Hide comment
@webron

webron Jan 30, 2015

Member

You understand correctly, it's just not implemented yet.

Member

webron commented Jan 30, 2015

You understand correctly, it's just not implemented yet.

@webron webron added this to the v2.1.0-M2 milestone Jan 30, 2015

@thegcat

This comment has been minimized.

Show comment
Hide comment
@thegcat

thegcat Jan 30, 2015

Ah, thanks a lot for the info :-) It seems the way to go is to define different models for read and write operations, I'll hold on to that until this is implemented.

thegcat commented Jan 30, 2015

Ah, thanks a lot for the info :-) It seems the way to go is to define different models for read and write operations, I'll hold on to that until this is implemented.

@avalon12

This comment has been minimized.

Show comment
Hide comment
@avalon12

avalon12 Feb 9, 2015

I'd love to see this feature implemented soon, so...

... +1

avalon12 commented Feb 9, 2015

I'd love to see this feature implemented soon, so...

... +1

@alekbarszczewski

This comment has been minimized.

Show comment
Hide comment
@alekbarszczewski

alekbarszczewski commented Feb 11, 2015

👍

@freewilll

This comment has been minimized.

Show comment
Hide comment
@freewilll

freewilll Apr 1, 2015

I've been looking into this too. I expected a readOnly parameter to be shown as being read only, in a similar way that non required parameters are being shown as optional.

The reason I expect this is because the API I'm documenting behaves this way: read only parameters are allowed in PUT requests, but are either simply ignored or checked to not have changed (I've not made up my mind yet on that one). The reason for this is because API consumers should be able to do a GET and then an immediate PUT without needing to delete the read only parameters.

I'd like the user to be aware of this behavior somehow. I've come up with a simple patch to do this. However it would behave differently than thegcat's assumption above. I wonder if there's something we can come up with to cover both cases?

Reading about this a bit more, the docs say:
"...it MAY be sent as part of a response but MUST NOT be sent as part of the request.". So I think what I want is the odd-case, so maybe not so appropriate...

freewilll commented Apr 1, 2015

I've been looking into this too. I expected a readOnly parameter to be shown as being read only, in a similar way that non required parameters are being shown as optional.

The reason I expect this is because the API I'm documenting behaves this way: read only parameters are allowed in PUT requests, but are either simply ignored or checked to not have changed (I've not made up my mind yet on that one). The reason for this is because API consumers should be able to do a GET and then an immediate PUT without needing to delete the read only parameters.

I'd like the user to be aware of this behavior somehow. I've come up with a simple patch to do this. However it would behave differently than thegcat's assumption above. I wonder if there's something we can come up with to cover both cases?

Reading about this a bit more, the docs say:
"...it MAY be sent as part of a response but MUST NOT be sent as part of the request.". So I think what I want is the odd-case, so maybe not so appropriate...

@Afbcary

This comment has been minimized.

Show comment
Hide comment
@Afbcary

Afbcary Jul 29, 2016

Has any progress been made on this?

Afbcary commented Jul 29, 2016

Has any progress been made on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment