Re:Best practices for REST API design (2020)
by vageli on Monday February 22, 2021 @05:27PM
(#26231532)
Many of the numbers we use day to day are more like strings than actual integers, though. What sense does it make to divide by a zip code, or two add two zip codes together for instance?
[ Parent
| on HN ]
Re:Best practices for REST API design (2020)
by Alex3917 on Monday February 22, 2021 @06:17PM
(#26231980)
This. Just because something contains numbers doesn't mean that it's numeric. Times aren't numbers because 6pm * 7am doesn't yield a meaningful result.
Same thing with serial numbers, VIN numbers, building floor numbers, phone numbers, etc. All of those should always be strings, because performing "math" on them wouldn't yield meaningful results.
Re:Best practices for REST API design (2020)
by chrisandchris on Tuesday February 23, 2021 @06:32AM
(#26236106)
While I basically agree, there‘s a difference between „always send numbers as string“ and „send something that looks like a number but is actually a string as a string“.
Why should i send a dimension as a string? How am I going to calculate the volume from 3 strings?
Re:Best practices for REST API design (2020)
by Alex3917 on Tuesday February 23, 2021 @08:53AM
(#26237210)
> Why should i send a dimension as a string?
You shouldn't because a dimension is a number. Something 4 feet long is twice as long as something 2 feet long.
Re:Best practices for REST API design (2020)
by MaxDPS on Tuesday February 23, 2021 @02:50AM
(#26234815)
I work in ecommerce and deal with this issue a TON. I see it in things like GTIN/UPC or tracking numbers.
Re:Best practices for REST API design (2020)
by chrisandchris on Tuesday February 23, 2021 @06:30AM
(#26236091)
Many != All
So prices are numbers (if supplied in cents, the smallest unit). There is length/depth/height/weight/... A lot of things are actual numbers. Why supply them as string?
I agree partially with you but think ZIP are a very bad example because a zip itself may also contain letters.