Add module category 'Decoupled', 'API First', 'Rest' or 'headless'.

As maintainer of the rest_menu_items module I support this initiative! +1 for REST

I'd never even heard of https://www.drupal.org/project/rest_menu_items! I updated #2732283: Menus: ability to retrieve all menu links for a given menu, regardless of whether a menu link is defined in content/config/code to point to it.

Added a bunch more to the issue summary.

I think "REST" is a less than ideal name because it doesn't cover non-RESTful API-providing modules, such as https://www.drupal.org/project/graphql.

I think "API-first", "decoupled" and "headless" are therefore slightly better choices.

Added https://www.drupal.org/project/rest_block_layout to the list.

I vote for "Decoupled"

I agree with @Wim Leers that REST doesn't cover some modules now and likely other modules in the future we haven't thought of.

"API-First" is more strategy for core(or contrib) development that makes Decoupled possible on all the things

I vote Decoupled.

Hearing other people use these terms, decoupled seems to be used in the most broad & general sense of the terms. It also makes the most sense to me as you are decoupling parts of Drupal to be controlled by something else.

As pointed out, REST is not used by all the above modules. So using the term REST would be as helpful as using the term SOAP. Well maybe a little bit more helpful, but still...

A quick Google search of Headless (as well as my own experience) refers to using something like Node as your front end. I think a lot of these modules are useful to users who do a Hybrid approach as well where Drupal still runs the front end but you use JavaScript to query the API somehow.

I'm not anti "API-First" but I tend to agree with @tedbow in the comment above mine.

Also slightly off topic but heavy kudos to those who created the above modules. JSON API & REST Menu Items have made my project much smoother! I really want to give the GraphQL one a try as well down the road.

As a webmaster, this feature request right fits for the Drupal customizations as this requires changes in Module project content type which should be featured in the code.
If you want to provide a patch for this issue. Please request for a new drupal.org dev environment site https://www.drupal.org/drupalorg/docs/build/development-environments/dev... See the similar issue https://www.drupal.org/node/2412081

//Naveen

+1 Decoupled. Less foreign than API First

@clemens.tolboom
Sorry, I didn't understand you.
I have pinged @drumm(Drupal Association Staff) to help with this issue.

//Naveen

Added decoupled.

clemens.tolboom is correct, these terms are not actually exported to code. (Some other vocabularies are.) I don’t know if webmasters have access to create terms in this vocabulary offhand; when in doubt, it is good to move the issue to this project anyway.

As Drupal.org webmaster, I can confirm that editing the taxonomy vocabularies requires a permission that webmasters don't have. It is required a user with a higher role, to edit them.

To make my previous comment more correct, webmasters can only edit the existing taxonomy terms, or delete them, not add new terms to the vocabulary. (https://www.drupal.org/admin/structure/taxonomy/vocabulary_3)