Timothy Jacobs

When a network error is encountered, API clients should be able to retry a request without a risk of their request being processed twice. 
WP API Idempotence adds support for clients to include an idempotency key that uniquely identifies that request. If the server detects 
that a request with the same key has already been processed or is currently being processed, the response for the initial request will 
be returned.
For Example:
<pre><code>{
 "title": "My Important Post",
 "content": "This will only go out once!",
 "status": "draft",
 "idempotency_key": "1ced64e9-9537-4b7b-9919-444d9e15e201"
}
</code></pre>
<h4>Configuration</h4>
<ul>
<li>Idempotency key can either be passed in the request header or the request body.</li>
<li>The idempotency key name can be customized.</li>
<li>Change the HTTP methods the idempotency key is supported for. Defaults to <code>POST</code>, <code>PUT</code>, <code>PATCH</code>.</li>
</ul>
A sample request interface is included to demonstrate the selected configuration.
<h4>Developers</h4>
The plugin includes two actions to modify the dependency injection container (DIC) and insert custom services.
The <code>wp_api_idempotence_initialize_container_builder</code> action allows you to modify the Dependency Injection builder itself and 
the <code>wp_api_idempotence_initialize_container</code> action allows you to override dependencies. For example:
<pre><code>add_action( 'wp_api_idempotence_initialize_container', function( $container ) {
 $container->set( '_dataStore', DI\object( 'YourName\CustomDataStore' ) );
} );
</code></pre>
Under the hood, the plugin is made up of a <code>DataStore</code>, <code>RequestHasher</code>, <code>ResponseSerializer</code> and <code>RequestPoller</code>.
The <code>DataStore</code> is primarily responsible for retrieving or storing an idempotent request. By default, requests 
are stored in a custom database table. This could be substituted for a custom driver by implementing the <code>DataStore</code> 
interface. For example a Redis server.
The <code>RequestHasher</code> produces a unique hash for a <code>WP_REST_Request</code> object. This hash is based off of the contents of 
the request, not for the object via <code>spl_object_hash</code> or similar. This can also be substituted by implementing the 
 RequestHasher interface.
The <code>ResponseSerializer</code> converts a <code>WP_REST_Response</code> or <code>WP_Error</code> object back and forth from a string representation. 
The default JSON serializer supports filtering the serialization process using the <code>wp_api_idempotence_serialized_response_data</code> 
and <code>wp_api_idempotence_attach_serialized_response_data</code> filters. See <code>src/ResponseSerializer/Filtered.php</code>. 
The entire serializer can be substituted by implementing the <code>ResponseSerializer</code> interface.
Finally, the <code>RequestPoller</code> class polls the data store for a response if it is determined that an idempotent request 
is currently being processed when another request with the same key arrives. By default, the data store is polled 
every seconds a maximum of 15 times to try and retrieve a response object. If no response is found, an error with code 
 rest_duplicate_idempotency_key will be returned. This can be adjusted by overwriting the <code>poll.sleepSeconds</code> and 
 poll.maxQueries in the DIC. The <code>RequestPoller</code> can also be entirely subsituted by implementing the <code>RequestPoller</code> 
interface.
<h4>Contributing</h4>
This plugin is hosted on <a href="https://github.com/iron-bound-designs/wp-api-idempotence" rel="nofollow ugc">GitHub</a>. Issues and pull requests are welcomed.

WP REST API Idempotent Requests

Allow REST API clients to safely retry requests in case of network errors without risk of the request being processed twice.

Dave McHale

Tang Rufus

The most comprehensive plugin for controlling access to the WordPress REST API!
Works as a “set it and forget it” install. Just upload and activate, and the entire REST API will be inaccessible to your general site visitors.
But if you do need to grant access to some endpoints, you can do that too. Go to the Settings page and you can quickly whitelist individual endpoints (or entire branches of endpoints) in the REST API.
You can even do this on a per-user-role basis, so your unauthenticated users have one set of rules while WooCommerce customers have another while Subscribers and Editors and Admins all have their own. NOTE: Out of the box, all defined user roles will still be granted full access to the REST API until you choose to manage those settings.
For most versions of WordPress, this plugin will return an authentication error if a user is not allowed to access an endpoint. For legacy support, WordPress 4.4, 4.5, and 4.6 use the provided <code>rest_enabled</code> filter to disable the entire REST API.

Disable REST API

The plugin uses a is_user_logged_in() check to grant access to disabled REST API endpoints. I run a membership site for one year and just realized it now, that any logged in visitor STILL HAVE ACCESS to any disabled REST API endpoints.

This should be very explicit, and there should be a setting in the plugin settings page to set the minimum role for the user to have access to the disabled endpoints.

ANY logged-in visitor can view the disabled endpoints


Blocking the REST API entirely breaks plugins that require this functionality, so being able to selectively enable routes is perfect.



I recommend this plugin to everyone who uses Independent Analytics to secure their site while still enabling analytics to be recorded.


Excellent solution


The plugin does what it says on the tin, without being pretentious. Absolutely fantastic!


Fantastic

Disable the use of the REST API on your website to site users. Now with User Role support!

WP REST API Idempotent Requests vs Disable REST API