Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Search API works with core Rest module's implementation on views "data" to return row field results, but not for entity rows.
Original issue
Something we came up with during our D8 BoF in Amsterdam: for better supporting HEADless Drupal et al., it might be a good idea to just provide an endpoint where you can execute any search (via GET parameters, no UI) and get the complete results (including facets, spellchecking, highlighting, etc.) back as JSON, XML or whatever.
Shouldn't really be all that hard to implement, one large issue might be security, though.
Or maybe implement it as a Views display, so people could configure it beforehand to exclude sensitive results (or restrict access to certain roles).
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2348117-12--views_rest_export.interdiff.txt | 625 bytes | ekes |
| #12 | 2348117-12--views_rest_export.patch | 3.81 KB | ekes |
| |||
| #2 | Screen Shot 2016-10-11 at 3.57.46 PM.png | 194.76 KB | veronicaSeveryn |
Issue fork search_api-2348117
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #1
drunken monkeyComment #2
veronicaSeveryn CreditAttribution: veronicaSeveryn commentedNot sure if I am posting inside the right issue, but is there a way to display Search API View result as JSON output at the moment?
I have tried creating a "REST Export" View output on a Search API Indexed based view, but it just returns empty results
Comment #3
drunken monkeyThat's a different issue, please create a new one. It does sound like something that should already work, though, so if it doesn't it might be a bug.
Comment #4
skorzhThat module can be useful in someone is looking similar for drupal 7: https://www.drupal.org/project/restful_search_api
Comment #5
malik.kotob CreditAttribution: malik.kotob commentedI wasn't able to reproduce #2. As such, I'm not sure that we need this issue any longer. With the advent of REST export displays in core views, you can create a REST export for each index as desired. From what I've seen, it also supports filtering, permissions, etc. just fine.
@drunken monkey, is there any reason why the REST export route wouldn't work for all backends? I've only tested with a DB backend.
Comment #6
drunken monkeyThis should be 100% independent of the backend plugin, so if Views REST export displays work with Search API, that's indeed a fix for this issue.
Can someone else confirm this works for them?
Comment #7
brunodboI created a REST export display on a Search API based view (as described in #2), and it worked for me with the 'Fields' display plugin: I was able to get JSON output of the view. When using the 'Entity' display plugin however, I got the error mentioned in #2858814: REST views: fatal error when using row plugin and Views is aware of non-Entity-based tables.
Comment #9
ekes CreditAttribution: ekes at Agile Collective commentedSo Rest Rows work; but entity doesn't. The core issue does highlight this, but seems broadened out. I can't fathom what core should be doing differently; but I can see how to make entity rows work with core rest module views.
Rest Entity Row plugin is: (a) getting a language manager for the entity type early on in the query and (b) retrieving the entity from
$row->_entity. Neither of which work with Search API views results.Just as Search API provides a SearchAPIRow plugin, you can provide a Row plugin for "data" results. Which on render returns the $row->_object->getEntity() if appropriate. See fork. It seems not to need the preRender() that SearchAPIRow has, $this->_object is always already loaded? With all the work the Rest Entity Row was doing for translation language, I wonder if this wouldn't need something to switch the language of the entity (but SearchAPIRow doesn't).
https://git.drupalcode.org/issue/search_api-2348117/-/commit/a2329e7fa5a... with all the unused use statements left in - oops. But you get the idea.
Comment #10
ekes CreditAttribution: ekes at Agile Collective commentedComment #11
drunken monkeyGreat job, thanks a lot! Seems to work a treat.
However, it also seems like the Views REST display can handle typed data instead of entities without problem, so actually no need to return
NULLfor non-entities (as far as I can see). Adapted your code accordingly, along with some other minor clean-up.Could you also tell me why you explicitly check for the existence of the datasource? Seems like that’s not needed in that code at all, and would anyways lead to lots of other errors in other places in the code. (For instance, item loading won’t work without the datasource, so in 99% of cases your first
ifwould already catch that case.)Uploading as a patch, since the test bot can’t handle our issue forks for some reason. (Cf. #3190024: Problem with test dependencies when testing issue forks.)
Comment #12
ekes CreditAttribution: ekes as a volunteer commented> Could you also tell me why you explicitly check for the existence of the datasource?
A cut and paste too far, in SearchApiRow the datasource is then actually used, here it's simpler.
Comment #14
drunken monkeyAwesome, thanks a lot again! Then this looks RTBC to me.
Committed. Thanks again!