Granted that spring supports this, but doesn't it seem weird that we'd model an object that is represented as a string in the path?

This for sure has a couple of work arounds

• Add an alternate type rule that maps a MyObject to a String
• Add an ignore rule for MyObject and add an api implicit param like you have above

Let me know if those work for you. I want to be careful not to introduce branching logic for these exception cases that adds complexity to the library for the 0.1% of the people using this library in this way.

Hi Dilip,

We model String into Object because we want to:

• add additional validation to String (e.g. using Validation Framework annotations or write some code in constructor)
• add additional methods to this object

Such modeling is also used for example in File and String. File object also represents a String with additional validation and methods.

Mapping from MyObject to String using directModelSubstitute(MyObject.class, String.class) works for me but it replaces also occurences also for body parameters. For now it works but I have to consider all cases. We have a lot of existing code we want to document with minimal effort and I don't know all consequences of doing it.

Using implict annotations also works but this is a lot of manual work.

I see some differences in generated JSON:

body paramater:

"parameters": [{
    "in": "body",
    "name": "myObject",
    "required": true,
    "schema": {
        "$ref": "#/definitions/MyObject"
    }
}],

path parameter:

"parameters": [{
    "in": "path",
    "name": "myObject",
    "required": true,
    "type": "ref"
}],

After applying workarounds you described JSON is:

"schema": {
    "type": "string"
}

and:

"type": "string"

so there are some differences in the code already regarding parameter type if parameter is path parameter. For body parameter we have schema and for path parameter we have just type. Maybe we could use this differences to implement feature we are disccussing.

I understand your consideration about code complexity and branching so please do not make any modifications now. We are considering to use SpringFox in our project but we are not sure we will use it. For now we have only a discussion about that.

@tjuchniewicz The use case seems reasonable, I'll make this a feature request.

However, (without any substantiative proof :)) I suspect that you'll need to adjust the constructors and accessors and mutators in just the right way in order reuse the MyObject elsewhere in the service, either directly or as a model property.

Yes, it is needed to make MyObject(String) constructors but for our current project it is already done.