eZ Community » Forums » eZ Publish 5 Platform » REST API: Recursively get objects.
expandshrink

REST API: Recursively get objects.

REST API: Recursively get objects.

Monday 23 February 2015 11:17:51 pm - 3 replies

Following HATEOAS principle is really great, however - say you want to get 10 location objects with the name of each location (using the /content/locations/<path>/children endpoint).

At the moment I need to run 1 + 10 + 10 requests for this single list of location objects. I believe this is not acceptable using AJAX from a web fronted - it's really, really slow. I can also see that is is a problem in the new PlatformUIBundle, the treeview that is. 

1. First get application/vnd.ez.api.LocationList = 1 http request

2. For each Location get application/vnd.ez.api.Location = 10 http requests

3. For each application/vnd.ez.api.Location get application/vnd.ez.api.Content = 10 https requests

So that is 21 HTTP requests to get a simple list of location objects including the "Name" field from the content object. 

Is there any possibility to recursively get objects from the REST API? Anyway to specify to fetch the relation instead of having to use the _href? 

Wednesday 25 February 2015 2:04:09 pm

You could extend the REST API as described here: https://doc.ez.no/display/EZP/Extending+the+REST+API

This is experimental code, it returns the ids and names of the children.

namespace BG\Bundle\ConsoleRestBundle\Rest\ValueObjectVisitor;
 
use eZ\Publish\API\Repository\Values\Content\ContentInfo;
use eZ\Publish\API\Repository\Values\Content\Location;
use eZ\Publish\Core\REST\Common\Output\ValueObjectVisitor;
use eZ\Publish\Core\REST\Common\Output\Generator;
use eZ\Publish\Core\REST\Common\Output\Visitor;
 
class Tree extends ValueObjectVisitor
{
    public function visit( Visitor $visitor, Generator $generator, $data )
    {        
        $visitor->setHeader( 'Content-Type', $generator->getMediaType( 'Tree' ) 
);
        $visitor->setHeader( 'Accept-Patch', false );
        
        $generator->startObjectElement('Tree');
        $this->_addTreeNode( $generator, $data->location );
        if( !empty( $data->locationChildren ) )
        {
            $generator->startList( 'children');
            foreach( $data->locationChildren as $child )
            {
                $this->_addTreeNode( $generator, $child );
            }
            $generator->endList('children');
        }
        $generator->endObjectElement('Tree');
    }
 
    private function _addTreeNode( Generator $generator, Location $location )
    {
        $generator->startValueElement( 'id', $location->contentInfo->id );
        $generator->endValueElement( 'id' );
        $generator->startValueElement( 'name', $location->contentInfo->name );
        $generator->endValueElement( 'name' );
    }
 
}

Friday 13 March 2015 9:02:27 am

I think maybe what Petter was getting at here was the high amount of HTTP requests being made. 21 requests is quite a lot for a list of 10 objects. I'm sure the effect is minimised if the latency is between you and the server is low, but it becomes unbearable if e.g server is in US while you're in Europe.

21 requests * 100ms latency = 2100ms = 2.1s. That's just in latency, never mind the time it takes to do the actual request, DNS, etc.

Saturday 14 March 2015 10:54:12 am

Hello there !

We are very, very aware of this topic. Our PlatformUI team is also affected by it. We have plans to improve this, and we'd actually be happy to share them with you. If it comforts you, they're quite short term plans. One key aspect is custom media-types support, where what is returned by the REST API can be enriched, like embedding the Content with the Location.

One thing you could try in the meanwhile is the content/views resource, e.g. search. There is an open PlatformUI pull-request where it is used to build the Content Tree, and it saves about 30% of requests. Note that it can also do multi-depth queries. You can see it in action in the DemoBundle's MenuBuilder.

None of those solutions are perfect, but they are what we will build up from to fix the problem. Our plan is to start specifying those more seriously in the last weeks, as we are getting started on the backend's subitems list. A first technical story we identified was adding support for Location Search in the REST /content/views. Another follow-up might be implementing support for persistence of views, as already specified in the REST API specification.

 Would you be willing to follow up the work and see how it would help with your particular use-cases and requirements ?

Modified on Saturday 14 March 2015 10:56:08 am by Bertrand Dunogier

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from