synopsis

Currently, when I make a call to a node I get the fields for a node, but any file fields give another callback url (which returns the actual file data) instead of the actual file data. This causes any clients using this to have to do extra calls to get a node's file data, which in some cases can add quite a lot of overhead. Can we not just return the file data with the original call?

example

I can make a call to /node.json and I get something like the following:

{ first: ...
  last: ...
  list: [{
    0: {
      body: {,…}
      ...
      field_photos: [{
        0: {
          file: {
            uri: "http://.../file/1"
  ...
}

calling the "uri" (http://.../file/1.json) then gives me the file info:

{
  "fid": "1",
  "name": "cannibal-cupcake.jpg",
  "mime": "image/jpeg",
  "size": "88956",
  "url": "http://.../sites/default/files/photos/cannibal-cupcake.jpg",
  "timestamp": "1361219862",
  "owner": {
    "uri": "http://copelandia.lulladev.com/user/2",
    "id": "2",
    "resource": "user"
  }
}

conclusion

If we can simply include this file data instead of a uri that has another callback, we can save a lot of resources in our clients.

Comments

sethviebrock’s picture

sethviebrock CreditAttribution: sethviebrock commented

Agreed. This makes it especially tricky to render an image field using something like http://drupal.org/project/backbone.

I can get at the file URI via {{ field_image.file.uri }} in a twig.tpl.php file, for example, but the template is not the place to make another call to RESTws.

See also #2035103: RESTws does not return file field data for images.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell commented
Priority: Normal » Major
Issue summary: View changes

This solution is actually more appropriate for the d.o need: #1710850-69: Deploy RestWS for D7 project issue JSON

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

I disagree with aggregate data on a normal resource.

While working on #2127965: Fix for the new json structure on d.o D7 I indeed needed to call a zillion request to get all files, comments and users.

The data needed for the requester depends on his/her use case.

The question here to be asked should be: "What's the hook to implement aggregation results?" as for d.o. we need a _full issue_ response while @sirkitree and @sethviebrock only want the files added.

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell commented

I don't think they want "only the files added". I think we're all on the same page. It makes no sense (for anyone) to return just the URIs to said resources when it has the potential to be so many. Instead, it should just include the data with it.

That being said, if there really is a option desired, is it possible to perhaps just add a toggle setting on the entity to "Include all sub-entity data"? If it's checked it includes the data, if not, it just provides the URI to the entity.

This begs the question though: "Should all sub-entities get expanded?"; probably not. Especially since comments can be quite lengthy.

So perhaps we should instead make the following toggle instead: "Allow this entity to be expanded in parent entities". I could see us enabling this for taxonomy and files, but not comments (at least for d.o's purposes). And then when, say, an entity references other entities, it checks if that entity has that option toggled and either 1) merges in the data or 2) provides the URI to that entity.

edit: just updated some verbiage to make it a little clearer.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

After done some testing on D8 rest and hal is disagree with my previous comment. In Hal context its result has an _embed element whose items could contain interesting items to add upfront into the result. In D8 we have a views REST display type too build up ie a node with it's relations. What is lacking is a display mode for JSON result.

Is the lack of display mode the missing part?

cjoy’s picture

cjoy CreditAttribution: cjoy commented

I want to expose a content type that contains a multiple taxonomy references and multiple image files.
I expected the JSON result for the node list to have resolved those references, but apparently thats not what happens.

Has anyone come up with an interim solution to this problem? (am I holding it wrong?)
Should I write a custom menu callback to serve the required JSON or do you handle the aggregation logic in the frontend?

pedrorocha’s picture

pedrorocha CreditAttribution: pedrorocha commented

The following post has a solution with a simple "?deep-load-refs" at the end of URL: http://dropbucket.org/node/659

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Issue tags: +affects drupal.org
TechNikh’s picture

TechNikh CreditAttribution: TechNikh commented

+1 to pedrorocha's comment in #7

jigarius’s picture

jigarius
Location Montréal
CreditAttribution: jigarius as a volunteer and commented

I found a drupal-friendly work-around without modifying anything in the core. If anyone is interested, they can read this:
http://stackoverflow.com/questions/37033484/drupal-services-direct-file-...