I'm currently building a cross-platform mobile app and headless web-app (https://github.com/CityWebConsultants/Drupal8-cordova-app) and so far I can register users, login, load views, view/edit nodes and next I want to allow users to create new nodes.

To follow the same approach as the main website, there needs to be:

1) A list of content types the user can use to create nodes.

2) Access to the schema of respective content types so that a 'node add' form can be generated on the client.

Are either or both of these services in the pipeline? I think at the very least 2 is a great feature to have and means node creation forms don't have to be hard-coded in headless apps which then causes a headache if the schemas do change on the backend.

Thanks

CommentFileSizeAuthor
#3 open_api.entities.json_.txt20.49 KBtedbow
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Adam Clarey created an issue. See original summary.

Wim Leers’s picture

Related issues:

  1. #2665602: Implement an API for REST clients to know which fields are editable
  2. #1925618: Ensure Drupal's web services are self-documenting: Swagger support OR rest_api_doc to Drupal core as an experimental module?

For the short term, I suggest you use https://github.com/acquia/waterwheel-js. There is an accompanying Drupal module: https://www.drupal.org/project/waterwheel. That contains a REST resource that does hopefully exactly what you need.

In fact, you providing feedback on Waterwheel's implementation would help a lot: it'd confirm it's a valid need, and it'd validate their implementation. Or it'd not validate their implementation, and point out gaps. Either way: please provide feedback!

tedbow’s picture

Version: 8.3.x-dev » 8.4.x-dev
FileSize
20.49 KB

@Adam Clarey as Wim said the Waterwheel module provides this.

It provides the specification for all entity types that are available via REST and their fields. The specification is in the OpenAPI format. This allows you to use many tools that are compatible with the OpenAPI spec but you can also just view the json output and figure out the resources for yourself.

The provided OpenAPI json is what the Waterwheel JS library uses to discover the resources schema. You maybe able to use the library in your project also.

The README for the module will tell you how to get the OpenAPI json: http://cgit.drupalcode.org/waterwheel/tree/README.md?h=8.x-2.x&id=546a17...

Here is sample json that module produces: https://www.drupal.org/files/issues/open_api.entities.json_.txt

Also I think any feature request would be for 8.4.x

GrandmaGlassesRopeMan’s picture

@Adam Clarey

If you get the Waterwheel Drupal module setup, you can have Waterwheel.js automatically setup itself with the available resources. Once that's done you can make requests using a consistent namespace.

Adam Clarey’s picture

After looking at the Waterwheel project I've decided it's not actually a suitable solution.

It requires a username and password for the requests which means you either store a users sensitive info locally in your headless app, or you require them to input those details every time a request is made. Both of these options is unacceptable.

I've been working with the jDrupal module/library for my headless app and its simple to use and allows for cookie based authentication. This is the right approach for most.

Also from reading about Waterwheel, even they disclose that some of their api endpoints are provided by the backend Drupal module but aim to depreciate that module as those endpoints (like i originally requested) will move into core.

So I think my original request for those endpoints is still valid.

Grayside’s picture

@Adam Clarey not to play contrib roulette, but https://www.drupal.org/project/schemata, which will have an alpha release with JSON Schema support soon (based on the significant refactor being wrapped up soon.

Wim Leers’s picture

Category: Feature request » Support request
Status: Active » Fixed

This issue asked for support, and it got that. We've explained where next steps are being worked on.

I already pointed to related issues in #2.

That's all we can do here, to be honest.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.