REST commands for Drupal 8

[weitzman]

Basically, wrappers around wget/curl calls like wget http://drupal.d8/admin curl -H "Accept: application/hal+json" --include --request GET --cookie SESS0xx=7VWxx http://drupal.d8/entity/node/2

Copied from https://drupal.org/node/1998974

[weitzman]

D8 REST docs at https://drupal.org/documentation/modules/rest

[weitzman]

The simplest solution here is to just call into command line Curl. The most complex and still interesting is to generate a Guzzle Service description based on how a D8 site is configured and then use it for Guzzle http calls. I'd be happy with either approach.

[weitzman]

Wordpress CLI commands are in planning. There is demo code in a Github repo - https://www.kickstarter.com/projects/danielbachhuber/a-more-restful-wp-cli?ref=project_tweet

[greg-1-anderson]

The big question is, is there a REST API in D8 that lists all of the available REST APIs? Looked for it, but not very hard; didn't see it.

[weitzman]

There is not, but one could build that in Contrib. A new API is called a @RestResource plugin. Core ships with 2 such plugins - an entity API (CRUD) and a dblog API

Also, Views displays can emit Restful results.

[geerlingguy]

Digging up an old issue, but I'm wondering—would this mean you could access Drush commands / API via HTTP? I'm trying to figure out ways to make Drush more useful/accessible in a 'cloud-native' world, where exposing SSH is a no-go (e.g. in Kubernetes), but I'm coming up pretty dry with ideas.

But one idea I had was having an HTTP API sidecar to the Drupal site that would expose Drush via a REST interface, and maybe the drush cli could be configured to operate via this interface instead of SSH?

Long term, that seems like an interesting approach, but it is a pretty big structural shift, and maintaining both would have to be done for some time as many people use Drush over SSH.

It looks like there was one attempt to do this with the Drush Webservice module half a decade ago.

[weitzman]

I dont think its Drush's role to extend Drupal's HTTP API. Drupal already provides extension points for modules via its REST and JSONAPI APIs. Those APIs each have their own problems (graphql can be a better approach) but Drush isn't going to magically solve them.

On a more helpful note, Drush aliases can already call into a DOCKER HOST and run commands on a service. The DOCKER_HOST can be local or a remote Docker hosting service. This feature assumes docker-compose but we could add a transport for kubectl. So perhaps we are already very close to seamless running on your cluster like drush @prod pm-security.

[weitzman]

Also, this issue was about calling into Drupal's REST API. We ended up implementing a jn:get command for making JSONAPI requests but never did REST.

Making Drush available via HTTP is a different kettle of fish.

[weitzman]

Drupal's REST API is not so popular. Anyone doing commands for it should start outside of drush core.