Articles
Renaming and disabling of resources and fields is now part of core.
When in need for altering resource properties like API path, resource counts or defaults for includes, or you want an interface to disable fields or resources, use JSON:API Extras.
JSON:API is entirely entity-based. That is, it can't process business rules or do things which can't be thought of as "CRUD". Business logic, like registering a new account, logging in a user, or requesting a new password are not part of JSON:API. Many of these are already provided by Drupal core.
A non-exhaustive list of common needs and solutions are presented below.
TL;DR
Choose REST if you have non-entity data you want to expose. In all other cases, choose JSON:API.
Slightly more nuanced:
Uploading files is now supported, see the release notes for more information: https://www.drupal.org/node/3024331
These two images show how to use postman to test file upload by JSON:API
Some sites may not wish to expose certain JSON:API resource types or fields or may wish to rename fields to provide a cleaner interface.
To allow these alterations, JSON:API dispatches a ResourceTypeBuildEvent event object using the event name ResourceTypeBuildEvents::BUILD. Please refer to subscribe to and dispatch events on how to use these events.
Subscribers can call the following methods:
This page shows examples of DELETE requests for the JSON:API module.
Enabling delete operation
Visit /admin/config/services/jsonapi
and check the "Accept all JSON:API create, read, update, and delete operations." option.
This page shows examples of PATCH requests for the JSON:API module.
Enabling update operation
Visit /admin/config/services/jsonapi
and check the "Accept all JSON:API create, read, update, and delete operations." option.
This page shows examples of various POST requests for the JSON:API module.
POST requests are used to create new resources. If you need to modify resources, you want to PATCH them.
This page shows examples of various GET requests for the JSON:API module.
In all examples below, no request headers are required. No authentication is required if anonymous users can access content entities. For config entities like menu's see last section(s).
Note that in all cases, when an id is needed, it is always the entity's uuid, not the entity id.
This section contains examples and information per request type: GET, POST, PATCH and DELETE
About the examples
All examples are working examples that you can try either in a browser or a JSON client (for example: Postman). You need a standard Drupal installation, a number of Article nodes and the JSON:API module enabled.