Timeline for How do searches fit into a RESTful interface?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Feb 15, 2017 at 2:54 | history | suggested | Zaaier | CC BY-SA 3.0 | GET isn't idempotent; it's nullipotent. |
| Feb 14, 2017 at 22:27 | review | Suggested edits | |||
| S Feb 15, 2017 at 2:54 | |||||
| Mar 21, 2014 at 15:14 | history | edited | sea-rob | CC BY-SA 3.0 | added 305 characters in body |
| Mar 21, 2014 at 15:11 | comment | added | sea-rob | I have the same gut feeling, that separating it by URI seems cleaner. I'm kind of going back and forth; it's a judgement call. However, the semantics of HTTP would allow putting it in the body. I like to say, REST is modeled after the World Wide Web, and the WWW was built with GET and POST. | |
| Mar 21, 2014 at 15:07 | history | edited | sea-rob | CC BY-SA 3.0 | added 758 characters in body |
| Mar 21, 2014 at 15:06 | comment | added | Rob Baillie | In terms of implementation (we're using Node and Express), it may mean the route can't really handle the choice of processing. I'd have to take a look at that... | |
| Mar 21, 2014 at 15:04 | comment | added | Rob Baillie | It's an interesting idea - I wouldn't have considered using the payload to differentiate. It almost seems a little underhand! But I guess the URI scheme doesn't actually contain any verbs - it's the request type that defines the verb. Maybe the payload is closer semantically to the request type than the URI is. The only concern is - Is it transparent to a user of the API? | |
| Mar 21, 2014 at 14:52 | history | answered | sea-rob | CC BY-SA 3.0 |