@ApiModelProperty dataType

[Wade Pearce]

Hi all,

Got a small issue that we're trying to overcome using com.wordnik:swagger-jersey-jaxrs_2.10:1.3.1.

We have request objects that are deserialized using Jackson JSON annotations.  We use primitives for the constructor, but the getters do the data conversion into some tiny type identifiers, JodaTime LocalDate and BigDecimal (from Double).

The problem we are having is that when we use @ApiModelProperty(required = true, dataType = "string") the type isn't reported as string, it's still reported as the actual type of the model getter.

We have tried: dataType = "string", dataType = "String", dataType = "java.lang.String" on both the field (which is of type String) and the getter (which is a tiny type identifier object) and the generated docs always say $ref: "Object".

Is there something we are missing?  Are we taking the right approach for describing the request API model?  

We can keep our request objects as primitives and delegate type conversion to somewhere else, but it adds bulk to the process for the sake of documentation.

Any help greatly appreciated.

Cheers,

Wade

[Wade Pearce]

Example code:

@ApiModel(value = "new order request")
@JsonDeserialize

public class OrderRequest {

    @ApiModelProperty(required = true, dataType = "java.lang.String")

    private final String customerNumber;

    

    // Other properties

    @JsonCreator

    public OrderRequest(@JsonProperty("customerNumber") String customerNumber){

        this.customerNumber = customerNumber;

    }

    public CustomerNumber getCustomerNumber(){

        return customerNumber(customerNumber);

    }

}

[Wade Pearce]

So, what I ended up doing is the following:

1. Created a model override to allow us to register these primitive wrapper types as a specific model type and have them represented in such a way in the JSON.
2. We're using our own handlebars.js template for driving the UI component, so it knows to pull up an internal property for the correct type for these.  Someone could obviously modify this in their own Swagger UI component.
3. Our in-house automated Swagger contract tester JUnit library now also knows how to interpret these wrapper models.

I must say that I am impressed by the toolset Swagger offers.  Sure...it's fun getting Scala Lists to happily co-exist with Java Lists, but it didn't take a lot to build our own DropWizard bundle that wraps all this up nicely for us and knows how to display and interact with our in-house API standards.

Overall, it's not exactly what I wanted, but it means the code drives our API docs more (ie. no missed data type change because of refactoring)

[Shu Zhang]

I have the same need. I wish the dataType just take a Java Class and use the layout of that for serialization. I'm trying to extend the swagger to achieve this. 

Is there plan to allow providing customized scheme override for fields/types?