[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cxs] Another productive Workgroup 3 session
My comments, inlined.
I thought about that option as well. However, the problem with this is that you don’t know the keys in advance which makes it more difficult to process the JSON object. On the hand, while the other solution is more verbose, it is also clearer as to the purpose of each elements in the structure and they can always be retrieved by their known keys.
Regarding this issue, which we already addressed previously, I’ll re-post the information I posted previously on the subject:
Another issue was whether to use POST or GET methods for queries in the endpoint. We settled on using POST which, after consideration make sense (if your resource is “queries” then, POST with data allows you to “create” a query).
Here are some links on the issue:
https://evertpot.com/dropbox-post-api/ (this one mentions the REPORT method which I wasn’t aware of)
Roy Fielding’s point of view on the question (via SO): http://stackoverflow.com/a/983458
Agreed, however, not with a GET method… ;)
I’d rather have all the request parameters in the same spot. So if we have a body, I’d prefer have all the parameters in the body instead of some in the URL and some in the body. However, if we are using the URL for parameters, we should strive to put all the parameters there as well and not use a body.
The idea of a generic query endpoint was to be able to do queries across object domains (e.g. joins) but it would be useless to have such an endpoint and not fully specify the query language and the expected results. We can probably try to do without initially.