Timeline for API design dilemma: to REST or not to REST
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 20, 2018 at 20:54 | comment | added | Sorter | This question needs more updates IMHO. | |
| Feb 5, 2016 at 11:57 | vote | accept | Mister Smith | ||
| S Feb 5, 2016 at 11:57 | history | bounty ended | Mister Smith | ||
| S Feb 5, 2016 at 11:57 | history | notice removed | Mister Smith | ||
| Feb 5, 2016 at 1:31 | comment | added | Andy | @gbjbaanb security.stackexchange.com/a/66476/17974 | |
| Feb 5, 2016 at 0:08 | answer | added | Tersosauros | timeline score: 3 | |
| Jan 31, 2016 at 23:45 | comment | added | gbjbaanb | @RichardTingle its not the ideal, but you do need to swap hashes between server and client - usually by encrypting a temporary key with the server that send you your stored hash encrypted with it, that you then compare. But you can do the same thing in the opposite direction. The moral here is not to try to implement security from a 29 word comment! | |
| Jan 31, 2016 at 22:15 | comment | added | Richard Tingle | @gbjbaanb surely that's not true. If the client hashes the password the hash is the password. Knowing the hash allows access to the system (you just set your client to send it directly, not hash it) | |
| Jan 31, 2016 at 18:53 | comment | added | RubberDuck | Maybe you can take some inspiration from GitHub's API. I can't say how RESTful it is, but I also don't care about such dogmatism. I only care how useful a thing is. | |
| Jan 29, 2016 at 21:27 | history | edited | Mister Smith | CC BY-SA 3.0 | added 6 characters in body |
| Jan 29, 2016 at 16:25 | answer | added | MvdD | timeline score: 6 | |
| Jan 29, 2016 at 10:44 | answer | added | dagnelies | timeline score: 9 | |
| Jan 29, 2016 at 8:52 | answer | added | gnasher729 | timeline score: 2 | |
| Jan 29, 2016 at 8:48 | history | tweeted | twitter.com/StackProgrammer/status/692992673553256448 | ||
| S Jan 29, 2016 at 8:38 | history | bounty started | Mister Smith | ||
| S Jan 29, 2016 at 8:38 | history | notice added | Mister Smith | Canonical answer required | |
| Jan 18, 2016 at 16:47 | comment | added | Robert Harvey | it looks almost impossible to force the stateful into stateless -- It looks like you think REST implies lack of state. But nothing prevents you from saving the result of a REST call in a database, or storing cookies on the client's browser, or performing any other meaningful action involving some state. "Stateless" just means that each REST call can act independently of the others, which is always true. | |
| Jan 18, 2016 at 14:37 | answer | added | VoiceOfUnreason | timeline score: 9 | |
| Jan 18, 2016 at 11:09 | history | edited | Mister Smith | CC BY-SA 3.0 | added 11 characters in body |
| Jan 18, 2016 at 11:09 | comment | added | gbjbaanb | never send the password itself, hash it (using bcrypt) and send the hash. The back end should also store the hash to compare against. Try asking on Security.SE | |
| Jan 18, 2016 at 11:03 | history | asked | Mister Smith | CC BY-SA 3.0 |