Timeline for API Inconsistencies
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:39 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Jan 10, 2012 at 1:32 | history | edited | Kevin Montrose | CC BY-SA 3.0 |
added 237 characters in body
|
| Jan 5, 2012 at 5:08 | history | edited | Kevin Montrose | CC BY-SA 3.0 |
added 4 characters in body
|
| Jan 5, 2012 at 4:58 | comment | added | Dave DeLong |
Badge and User have a many-to-many relationship. Proper decomposition mandates that the way to model that correctly with a -to-one relationship on one side (which is what JSON can handle) is with another object, the Awarded Badge. I understand that text searching is expensive. It's just frustrating to think "ok, this had inname, that had inname, this should to. Wait, it doesn't? wtf?".
|
|
| Jan 5, 2012 at 4:54 | comment | added | Dave DeLong |
(Comments in order) I'm willing to let things like hot, week, and month slide as sort values on questions, because there's no way for clients to duplicate the algorithm used to determine the "hotness" of a question. But I maintain that consuming the API is not the same thing as using the site. The API is for us developers, and thus it should be consistent. If I'm sorting by the score of a question, then don't call it votes, call it score. If I'm sorting by when an object was creation, don't call it creation, call it creation_date. The sort key should match the object field.
|
|
| Jan 5, 2012 at 4:16 | history | answered | Kevin Montrose | CC BY-SA 3.0 |