REST Expose Documentation (Swagger) - Cast integer as integer string value

REST Expose Documentation (Swagger) - Cast integer as integer string value

  
Dear Outsystems


When an integer entity identifier is defined via swagger documentation, please cast the integer as integer “string” value.

This will allow Outsystems to provide future support for long/int64 data type aswell.
 

If you output the value as a int64 value, there will be issues with Javascript. JavaScript has no 64 bits integers, it only has a number type, and is a IEEE754 double precision float, this is only precise up to 53 bit, and can not support numbers greater than 53 bit, it will cause an issue for everyone when you decide to upgrade from int32 to int64.
 

Both Facebook Id's and Twitter Id's have casted int64 as a string value.
Facebook cast all Id integer as integer string value and solves the problem in one go. Where as twitter they fix this issue with a work around solution and have an extra attribute to output int as string. Int_str i.e 
Twitter recommends you use int_str see https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake

Please avoid making this mistake, then have to make a breaking change on a public web services to fix this issue later on! Update the swagger json defination file and cast integer as a string integer value.

 

That's one good idea Robert. I hope it is implemented.
That certainly looks like something that you can do by yourself, where needed.

If you have an identifier which is a 64 bit and are adding it to the structure of an exposed REST API you can add an extra parameter id_str which is a conversion of the id to string. You needn't do this for all identifiers if you don't expect them to grow beyond 53 bits ( 4503599627370495 ) .
Ricardo Silva wrote:
That certainly looks like something that you can do by yourself, where needed.

If you have an identifier which is a 64 bit and are adding it to the structure of an exposed REST API you can add an extra parameter id_str which is a conversion of the id to string. You needn't do this for all identifiers if you don't expect them to grow beyond 53 bits ( 4503599627370495 ) .
It really depends on how outsystems is to implement bigint/int64/long.

Will outsystems keep int32 and int64 as seperate datatypes? (I hope so! not everyone needs int64. Int64 has its advantages and disadvantages, just like everything, you got to use the right tool for the right job!) :)

It might even be ok to cast int64 as long too! but casting int64 as a 32bit integer and causing data lost is definately not the right way to do it! 
 
I will have a meeting with outsystems this week, after that I should be able to have a better understanding on how outsystems implemented bigint/int64/long and from there I could provide better feedback/technical design consideration... to finally solve this bigint issue!