Remove REST module's UI

So you will point to the active storage cmi yml files? Because the ones in the module are only used at installation time.

I definitely applaud no UI's :). Given that we are in cleanup phase, I would be even more inclined as there will be to little time to make a useful UI.

There is no correct way. IRC chat message:

aspilicious: because the hooks on import will not run
aspilicious: it won't matter for 'easy' configs like site name or so
aspilicious: but harder ones can be tricky, especially config entities
which need to fire pre/post etc hooks
so we probably need a config editor in contrib that prins the content of a .yml file on screen and saves it when you press "save" and launch all the hooks
aspilicious: yeah, that's fine, just don't hack it manually

Apparantly there is a drush command to open a .yml file and that one runs the import hooks.

Fixed a small typo (entitis -> entities). And - after speaking to tstoeckler - also a small text revision.

Removed superfluous placeholder var. Rerolled as per IRC. Interdiff is against #8.

+++ b/core/modules/rest/config/rest.settings.example.ymlundefined
@@ -0,0 +1,24 @@
+    # Allow updating nodes ony in HAL or JSON
+    PATCH:
+      'hal': 'TRUE'

I think this should be "only in HAL". The rest looks good to me.

Sorry for not being more specific. I think you meant "only" not "ony"

Much better sample. Thanks, klausi!

The example yml file is great.

typo: resourse

' . t('Edit the <em>rest.settings.yml</em> file in your active configuration to determine which resources (entities) should be exposed.') . '</dd>';

Better (I think) is: Copy rest.settings.example.yml to the staging configuration directory, rename file to rest.settings.yml, edit as needed, and import new configuration.

Excellent.

Wow. :( Very sad to see this patch. :( I mean sure, the UI's not perfect, but it does make this functionality far more accessible than hand-editing code files.

This probably deserves a Dries sign-off, IMO. While it's true that setting up a REST server involves some amount of technical competence, so does setting up SQL-powered listings, pulling in data from external feeds, etc. We provide UIs for all of those; in fact, I'd argue that this is the whole point of Drupal; to make really techy tasks accessible to mere mortals who can submit forms.

The issue summary does a good job of laying out why you want this to be done.

But one thing that's not clear to me from the issue summary is this:

" it is difficult to implement a proper UI for REST module that covers all possible configuration options"

Can you be more specific on the possible configuration options not covered by the current UI? Because the current UI seems to cover per-entity REST endpoints, as well as per-role access to each method on those endpoints (GET, POST, PUT...). One area I find missing relative to the example YAML file is selecting the format (XML/JSON), but that's just a simple select box for the 99% case.

I'm sensitive to not putting more on your folks' plate than you have already, but at the same time I feel like the UI is at least 85% there already, and so I'd love to understand where I am missing a cluebat.

Btw, if what's really blocking this is questions on how to implement crazy hierarchical settings type stuff, the content translation UI is exceptional for this (and user-tested!), and has some patterns we could just copy/paste.

If however, it's the ability to do kind of "out-there" stuff like arbitrarily allow JSON on GETs for entity A but XML on POSTS for entity B, I guess I'd question whether or not the UI needs to cater for that at all. Someone with those kinds of advanced needs could just take the YAML file and hack it.

webchick: I think in a large part it comes down to "do we spend the next 2 months answering comment #28, or the next 2 months adding more hypermedia relations and ensuring that embedded resources can be handled cleanly from contrib and so forth?" The general consensus from the REST team was that we'd rather focus on the latter and avoid the extra work of refining the UI and discussing the questions in #28, as that would just slow down functionality refinement.

Since it's "just" a CMI file, contrib can experiment to its heart's content with good UI models here. I would actually be completely OK with a UI coming into core in 8.3 or 8.4 or something once we've got a better idea of what it should be. But especially for API-centric stuff like this, good code design first, good UI design second.

A potential compromise would be to open a contrib project now so we're not losing the functionality we already have?

As much as I'd love to see a UI for this in core, I don't think it is key to focus on this right now. We have plenty of more important things to do at this stage of the release cycle. I support removing this for now.

We could decide to bring this back in before or after we ship 8.0.

webchick said she wanted to give the patch one more look before commit.

Ah well, you can't win 'em all. :)

Sending for a re-test first.

#24: remove-rest-ui-1927162-24.patch queued for re-testing.

Apologies for brevity, just wrapping up a call real quick, but a few issues:

- Configure link on .info file still showing up even though there's no page
- The example to copy/paste should be a useful example that makes sense for 80% of sites. The node stuff looks good, but the rest of it should be moved to a handbook page and linked at the top of the file for more advanced examples.
- There's a missing step in the help text of enabling one of the "serialization format" modules (e.g. HAL), else you get a 405 "Method not allowed" when trying to copy/paste the GET command.
- The config import Diff feature broke with an AJAX error when I tried to initially diff the staging rest.settings.yml with the active config, we hypothesize this might be due to REST module not providing its own default. The default should probably be totally empty, else we could maybe do something like "enable node GET on JSON" so that the examples work.
- The GET command worked, the DELETE command didn't, but I believe that's already covered in a separate issue.
- However, please rename node/5 to node/1. :D

Once those are addressed, looks good to me. Thanks!

Hm. My feeling is that with the UI removed, this help page *becomes* the UI, so yes, it is in scope to make the text/examples correct (except where there's a bug in some other issue like in the case of DELETE).

And while I realize it's next to impossible to make a call on what makes sense for 80% of sites, I can tell you definitively that the example you provide here and tell people to copy/paste into their staging directory does *not* make any sense for even 1% of sites. :) But people may or may not realize that until they're much further along their learning curve. The example text here is "demoware" to show all of the flexibility of what can be done. And that is all good information, but not coupled with what is sure to become the default config for at least 80% of sites who play around with this module. I'd simply do "For more advanced route configuration, see [url]" from the actually useful example that you tell people to copy/paste, and then that handbook page can grow organically with other examples added by other people.

And yeah, I can no longer reproduce that error in a fresh install in an "incognito" window of Chrome, so that must've been stale JS from before the dialog patch this morning. Sorry about that.

Embedding inline like that makes sense to me, especially with the main documentation on d.o instead.

Committed 3ed3a45 and pushed to 8.x. Thanks!

Interestingly this means these instructions will need to change when we change the config importer to only handle whole sets of config.

This piece of logic has been restored in REST UI module.

added proposed solution