add support for /api/node/{type} and/or /api/v2/node/{type}

[ps23Rick]

I know that other JSON implementations (e.g. the Drupal one I used recently) allows querying all nodes of a specified type without the need to specify any {id} values. This will return, in these implementations, all the resulting node-ids of the specified type. This is currently missing and I'm willing to add the support if it's of interest. Also, if there's an alternative way to achieve this through the existing support, I'm open to using that.

For instance, my code that currently works with Drupal can query all nodes of custom type {navpage} using the Drupal API : http://localhost:8888/drupal/jsonapi/node/navpage and then it can weed through the results. I should note that in this case the result set is always very small and no pagination is required.

I tried defining a backdrop view for this type {navpage}, and told it to display everything, no pagination, no menu, unformatted, unsorted. I can pull that view up just fine and see the content using only the backdrop URL, but when I enable the respective view within the headless module, it just returns this terse information as shown below :

{"results":[{"nid":"3"}],"count":1}

I was hoping it would return the entire content block for that particular navpage item..I looked at the code for the views module and it apparently only returns those items. Hmm...

---

PR: #42

[serundeputy]

Hello @ps23Rick !

If the view had fields on it it would return the node fields. That is how i always use it in conjuction w/ headless module.

This page: https://api.serundeputy.io/api/v2/views/archives_api/page
provides the data for this page: https://serundeputy.io/archives

for example.

That said I'm not opposed to adding collection support for the types the user opt into the API.

[ps23Rick]

Hmm.. I went back and reviewed my "view" settings and you were right -- I had chosen unformatted output and that disabled the fields setting. I forced it to be turned on but still didn't get anything meaningful for some reason. With that said, assuming that you're OK with me doing so, wouldn't mind implementing either one of the following APIs as an extension of the existing node handling:

api/node/{type}

OR

api/nodes/{type}

I believe I've seen both implemented as part of different JSON implementations for different CMS's. Just let me know what you want to do.. If you're OK with moving forward, I'll try my best to tackle it today.

[serundeputy]

I'm fine w/ you moving forward on this. I think i'd use api/node/{type}.

[ps23Rick]

ok.. I'll proceed then using api/node/{type}.

[ps23Rick]

ok.. stupid question to ponder.

In the cases where a bunch of nodes can be returned, do you want to do pages/ranges of the resulting data? This is not really an issue for me as my datasets will be very small -- like probably under 10. However, I realize that others may have much larger data sets. Currently my initial code will gather up to 10 items from the database before returning. I've not bothered looking through the other parts of the headless code to see if it handles pagination or just grabs whatever is there. Maybe the existing code never had to deal with this scenario. Thoughts?

[serundeputy]

The views endpoints handle pagination, but that might be from the view query and not the api query.

[serundeputy]

yeah; looks like the pagination is handled on the views end for headless_views_v2.

So you'll need to include pagination in your sql query.

[ps23Rick]

ok.. Initially I'll keep things simple just to ensure the underlying queries are working and being provided back as JSON and will implement the pagination after the initial stuff is working as expected. Agreed. I just looked at what you indicated and see the pagination code (_views_get_view_result) referenced

[serundeputy]

I think something like this will work

$sql = db_select('node', 'n')->extend('PagerDefault');
$nodes = $sql
  ->fields('n', array('nid'))
  ->limit(4)
  ->execute();

foreach ($nodes as $node) {
  print_r($node);
}

[ps23Rick]

Right now I'm using the following code to pull up the list of nodes of {type} and it appears to be working quite well -- I found it as part of a search..

  // load the requested node and check to see if types match or not
  $query = new EntityFieldQuery();
  $query->entityCondition('entity_type', 'node')
        ->entityCondition('bundle', $type)
        ->propertyCondition('status', 1) // get only published items
      // It returns the first 10 nodes.
      // Use range(10, 10) to get the next 10 nodes.
        ->range(0, 10);  
  $result = $query->execute();
  if (isset($result['node'])) {
    $nodes = entity_load('node', array_keys($result['node']));
  }

Is one better than the other? I've got no idea frankly...

[serundeputy]

You can also use devel_generate if you want to generate 100s or 1000s of nodes for testing.

drush dl devel

drush en devel_generate

drush help genc

[serundeputy]

EntityFieldQuery is fine.

[ps23Rick]

thanks.. I'll see how far I can get -- the pagination complicates things a little. it's not likely to be done today though.. So much for my running streak! lol

[serundeputy]

for pagination we can use url params like /api/v2/node/page?page=2 etc default to page=1;
https://api.backdropcms.org/api/backdrop/core%21includes%21common.inc/function/backdrop_get_query_array/1