[Proposal] Automatically set type to Integer for entity 'id' fields

[Fs00]

Hello!
We noticed that the default type that gets added to Swagger docs is string for all fields unless otherwise specified, which is already good in most cases.
However, when we create a new entity we often find ourselves writing the following line (when we don't forget about it):

expose :id, documentation: { type: :integer }

Given that probably 99% of Rails apps out there use integer IDs for their entities, wouldn't it be great if Grape automatically set the type to Integer for id fields? The user would then still be able to override it with the most appropriate type if needed, as now happens with all other 'string-by-default' fields.

I'm not sure if this is the right repo where this feature should be requested (maybe grape-swagger? or grape-entity?), feel free to move this issue into the more appropriate one.

[kzaitsev]

Hello, @Fs00.

I can understand your point, this might be reasonable for some projects to set the default field type by the naming convention (if the type is not specified). But someone can use UUID, hashed integers (https://hashids.org/) which present as a string, and changes of default type can be very breaking, that's why I prefer to keep this behavior.

unfortunately, I don't have much time now, I can suggest to you, to make a feature to the grape-swagger, which allows you to intercept fields with unspecified types, and return a definition hash that can be merged into type definition. For example something like this:

Grape::Swagger.unspecified_type_interceptor = proc do |field_name|
  case field_name
  when /id/
    {type: :integer}
  when /*_at/
    {type: :string, format: 'date-time'}
  else
    {type: :string}
  end
end

When something like this will be implemented, this can be adopted by this project (grape-swagger-entity).

What do you think @LeFnord ?

[Fs00]

Thanks for the quick answer @Bugagazavr! I think we will continue to go with the "conventional" way for now, but we'll keep an eye on any addition that might help us make entity definitions DRYer 😉
Feel free to close this.