Currently RestWS only allows to access entity via it's id, but in many cases you don't know the id, so it would be cool to have features like to retrieve all entities of a certain type or search for entities with certain properties using EntityFieldQuery.
This functions need to have some sort of paging system, in case there are to many Enities and the question is how should this system work?
One possibility is, that that every result has a link to the next page. Another would be, to specify the pages in the query...
What do you think, RestWS Community?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 1494124-querying-and-paging5.patch | 9.18 KB | sepgil |
| #11 | 1494124-querying-and-paging4.patch | 9.61 KB | sepgil |
| #8 | 1494124-querying-and-paging3.patch | 8.57 KB | sepgil |
| #7 | 1494124-querying-and-paging2.patch | 8.6 KB | sepgil |
| #4 | 1494124-querying-and-paging.patch | 6.64 KB | sepgil |
Comments
Comment #1
klausiTagging
Comment #2
sepgil commentedKlausi and I discussed how I should implement this task and what we came up with, is that to make a basic query which simply returns all nodes, the client has to use HTTP GET method on the base uri of the resource.
So if you want to get all nodes, you'll have to retrieve them with the GET method on the uri node, node.js or node.xml.
If want to do a query you'll have to specify the query parameter via a question mark.
For example, if you want to get all nodes of the type article from the author foo the uri has to look like this:
node?type=article&author=foo
If the there is an entity property colliding with a name used by restws, you'll have to use the prefix "property_".
To prevent DoS attacks and we'll also have to use some sort of paging(like described in the post above). I did some research and found out that it would be best to implement the system described here:
http://tools.ietf.org/html/rfc5005
We will have four key elements called "first", "last", "prev", "next" which will help you navigate through several pages, with each page having an uri like "[entity]?page=[n]".
This means, we will have to change the current output format a little bit to distinguish actual values from restws metadata.
My suggestion would be to have an element/object which contains all values, and have all metadata about paging on the first level of the hierarchy.
Json example for nodes:
node?type=article&page=2
XML example for users:
user?page=4
Comment #3
sepgil commentedAnother thing I noticed, is that restws should by default only output a reference to the entities like:
and only if the client uses the parameter "full=TRUE" all properties of the entities should be outputted.
That would reduce the load on the server.
Comment #4
sepgil commentedI've created a basic patch to test out the functionality.
Currently it simply lists all resources if the either /resource.json/xml is called or if the right http header are set.
Comment #5
klausiqueering should be querying. Exception type RestWSException.
better name: filters?
@return array
additional parameter: "meta_controls" for sorting, paging etc.
query limit is missing: variable restws_query_max_limit 100
this should be checked for emptyness
couldn't you use array_keys($query_result)?
not related to create, use your own if branch.
you need to do that for all formats available
should be "elseif"
"{" should be on the same line as if
Otherwise looks pretty good so far.
Comment #6
klausiOh, and simpletests please!
Comment #7
sepgil commentedNew version of the patch is out, now with simpletests ;-)
Comment #8
sepgil commentedForgot to delete a debug statement...
Comment #9
klausi@param docs for meta_controls is missing. both parameters should have array() as default.
same array() defaults here
should be "want"
use array() instead of NULL
WTF?
do not use the label, use the array keys as identifier for formats
That is fine, but we need to check for the query operation in restws_handle_request() and use view instead.
100000 white space issues.
same test for XML please
Comment #10
sepgil commentedBeside fixing the issues mentioned above, this patch also changes the output format so it fits the description in the posts above.
Comment #11
sepgil commentedwtf? I don't know what happened with my post above, but here is the patch.
Comment #12
klausishould be querying
should be "throw a RestWSException"
should be "filters"
should end with a simple dot.
unrelated change
unused?
description is wrong
I think the default should be an array() not NULL.
should eb "no" instead of "now"
should be "elseif"
better name: resource_arg to match id_arg
you could also assert if the outer list element is present.
Comment #13
sepgil commentedFixed all the problems, I think it should be ready to commit now. I'll open follow up issues for the additions features like sorting, paging and query filters.
Comment #14
fago+1 for going with next/previous links.
In particular for XML, pls try to avoid coming up with something new, but better follow the atompub specs: http://tools.ietf.org/html/rfc5023#section-10.1
I don't think there is something as widespread for json, but at least google has a direct json port from atompub, so just going with a similar structure in json is probably a good idea as well.
Comment #15
klausiImproved some comments and details and committed it, thanks!
@fago: paging will be a separate issue, this one is just about very basic querying without any filters and pagers.
@sepgil: please open follow-up issues for filtering, paging and sorting. And link them here.
Comment #16
sepgil commentedThe first follow can be found here: #1697514: Querying - Filters
Comment #17
sepgil commentedI made a separate issue for Meta Controls: #1698644: Querying - Filters & Sort Meta Controls
Comment #18
sepgil commentedPaging is beeing implemented in this issue: #1700098: Querying - Paging