Confirmed users
1,136
edits
(→Q&A: Throwing the Post to create query results pattern out there) |
|||
| Line 54: | Line 54: | ||
** I think it's pretty easy to handle either case, but since we'd potentially be dealing with arrays of plugins I'd opt to accept a JSON body and have the app run logic on it. | ** I think it's pretty easy to handle either case, but since we'd potentially be dealing with arrays of plugins I'd opt to accept a JSON body and have the app run logic on it. | ||
** One argument against using POST is that doing so doesn't give you a good cache hit rate and could possibly crush the service doing operations that otherwise could be easily cached (albeit with an increase in HTTP requests). | ** One argument against using POST is that doing so doesn't give you a good cache hit rate and could possibly crush the service doing operations that otherwise could be easily cached (albeit with an increase in HTTP requests). | ||
** A Post to create query pattern might resolve cache issues | |||
* Will there be a batch request mode, or 1 request per plugin? | * Will there be a batch request mode, or 1 request per plugin? | ||
** Leaning towards 1 request per plugin at this point, but we should take some time to figure out which solution is best. | ** Leaning towards 1 request per plugin at this point, but we should take some time to figure out which solution is best. | ||
== Post to create query results pattern == | |||
# client POSTs JSON body server | |||
# server hashes the request parameters and stores work request in queue or db | |||
# server redirects request to the location which contins contains the actual results | |||
# client GETs results url | |||
# cache miss, retrieve work or results from queue or db by hash | |||
# subsequent requests hit cache | |||
Related: http://en.wikipedia.org/wiki/Post/Redirect/Get | |||