Allow to set referenced schema property as readOnly

Feature Request
1

Hi,

Please take a look at the Screenshot #1. For me this feels like a pretty obvious use case - to be able to have referenced element as readonly/writeonly in the context of the schema that references it.

The lack of it limits usage of components drastically, at least in our APIs. I have to create a new copy of a schema just to mark the same object as readonly in few contexts.

Please consider at least supporting a manual entry (Screenshot #2)

image.png
image.png1288×608 74.8 KB

image.png

1 Like
2

Thanks for the feedback. Could you please describe your usage scenario in detai? It would help us understand your needs better.

1 Like
3

Sure,

For example, in our API we have a common way to represent internationalized content. For example, let’s say I have a Post and it has title, slug and body:

{ 
  "post": { 
    "title": { 
      "en": "Helo",
      "es": "Hola"
    },
    "slug": {
      "en": "helo",
      "es": "hola"
    },
    "body": {
      "en": "Welcome",
      "es": "Bienvenido"
    }
  }
}
4

As you can imagine, there would be a lot of duplication to describe each attribute on each model

5

So, i’ve created a schema like this (it’s more complicated, i left only what is relevant here) to describe such structure, let’s call it LocalizedContent:

6 
{
  "type": ["object", "null"],
  "examples": [
      { "en": "Text" }
  ],
  "additionalProperties": {
      "type": "string"
  }
}
7

However, It does not make sense to set “readOnly” property on this schema globally, as some model attributes are readonly, and some are not - for example Post has editable title and body, but slug is autogenerated

8

In other words, when i reference LocalizedContent on Post’s attributes, I need to specify that slug is readonly. Without it, I would have to create a “readonly” version of this schema ([READONLY] LocalizedContent :D) or just copy-paste it without reference.

Both workarounds feel hacky and untidy to me.

9

The example above may feel a bit complicated and specific to just one case, but because of the same issue, we cannot fully efficiently use “primitives” like these that make the whole API specs more clean and DRY:

image.png
image.png1603×970 83 KB

image.png
image.png1603×970 83 KB

10

I hope you can imagine that specifying “readonliness” of “primitives” like these globally and statically doesn’t feel very natural :smile:

11

Sure,

For example, in our API we have a common way to represent internationalized content. For example, let’s say I have a Post and it has title, slug and body:

{ 
  "post": { 
    "title": { 
      "en": "Helo",
      "es": "Hola"
    },
    "slug": {
      "en": "helo",
      "es": "hola"
    },
    "body": {
      "en": "Welcome",
      "es": "Bienvenido"
    }
  }
}
12

So, i’ve created a schema like this (it’s more complicated, i left only what is relevant here) to describe such structure, let’s call it LocalizedContent:

13 
{
  "type": ["object", "null"],
  "examples": [
      { "en": "Text" }
  ],
  "additionalProperties": {
      "type": "string"
  }
}
14

However, It does not make sense to set “readOnly” property on this schema globally, as some model attributes are readonly, and some are not - for example Post has editable title and body, but slug is autogenerated

15

In other words, when i reference LocalizedContent on Post’s attributes, I need to specify that slug is readonly. Without it, I would have to create a “readonly” version of this schema ([READONLY] LocalizedContent :D) or just copy-paste it without reference.

Both workarounds feel hacky and untidy to me.

16

I hope you can imagine that specifying “readonliness” of “primitives” like these globally and statically doesn’t feel very natural :smile:

17

We actually have a similar use case where we reference Schema in our requests model, but for the “PATCH” operation on another service, we only want the “write” options to show of that service, not it’s relation. However, with the schema referencing another “entity” that is actually managed by another endpoint/service, it looks as if you can “update” fields of that entity even though it’s not possible.

In other words, allowing for the “read-only” of referencing another schema for a field should make that field not “updateable” in the API requests definition of method that update a Schema.

Thanks for the great work by the way ;).

18

Thank you for your detailed feedback and use case explanation! I’ll share your requirements with our product team for evaluation. We’ll keep you updated on any progress regarding this feature.