renemanqueros

<p>Allows developers to create REST-ish API’s that have access to all of WordPress and its plug-ins objects.</p>
<h3>Usage</h3>
<p>Install the plug-in as any other plug-in.<br />
Project is divided in two sets of files:</p>
<pre><code>* index.php - This is where you register routes and/or middleware.
* routes/ - This is where you place your routes.
</code></pre>
<h3>Middleware</h3>
<p>Middlewares are functions that will be executed on every call to the API, generally used to validate parameters or<br />
transform requests before they reach routes, code for middleware is structured like this:</p>
<pre><code>app::middleware(function () {
    doSomething();
});
</code></pre>
<ul>
<li>Middlewares run for every Verb and do not automatically assign $_POST or $_GET to any variable</li>
</ul>
<h3>Routes</h3>
<p>A route is where you would link a request to a function depending on its HTTP Verb.<br />
The routing engine will prepend /api/ to all calls and will append a trailing slash to all requests.<br />
A GET request would be matched like this:</p>
<pre><code>app::get('/testget', function($req){
   return $req;
});
</code></pre>
<p>In which:</p>
<pre><code>* app::get - This will match up a GET request.
* '/testget' - the path the routing engine will look for.
* function(){ } ... - the function to execute when the route is matched.
* $req - parameters sent to the verb.
</code></pre>
<p>To make a call to this route, the full path would be:</p>
<pre><code>http://www.mysite.com/api/testget/
</code></pre>
<ul>
<li>The trailing slash is always required.</li>
<li>Parameters for all routes will be sent as the first parameter to the callback.</li>
</ul>
<p>A route should be registered on the index file by placing a call to app::routes with the filename of the route (without the extension) as a parameter:</p>
<pre><code>app::routes('test');
</code></pre>
<ul>
<li>All routes output their return value as a JSON encoded response.</li>
</ul>
<h3>Samples for all verbs</h3>
<ul>
<li>
<p>GET:</p>
<p>app::get(‘/testget’, function($req){<br />
   return $req;<br />
});</p>
</li>
<li>
<p>POST:</p>
<p>app::post(‘/testpost’, function($req){<br />
    return $req;<br />
});</p>
</li>
<li>
<p>DELETE:</p>
<p>app::delete(‘/testdelete’, function($req){<br />
    return $req;<br />
});</p>
</li>
<li>
<p>PUT:</p>
<p>app::put(‘/testput’, function($req){<br />
    return $req;<br />
});</p>
</li>
</ul>
<h3>Nested routes</h3>
<p>Routes can be nested like this:</p>
<pre><code>app::delete('/admin/machines', function($req){
    return $req;
});
</code></pre>
<p>Which could be called by issuing a DELETE to:</p>
<pre><code>http://www.mysite.com/api/admin/machines/<h3>Route and middleware registration</h3>
Code for the routes should be placed on a file inside the "routes" folder and then "registered" on the index.php file like this:
</code></pre>
<p>function gp_registerapimethods()<br />
{<br />
    app::middleware(function () {</p>
<pre><code>});

app::routes('test');
</code></pre>
<p>}</p>
<p>Only one instance of the gp_registerapimethods should exist on the index.php file.<br />
Middleware and Routes can have as many instances as needed.<br />
All routes inside the routes folder can be registered by doing this call instead of the individual route registration:</p>
<pre><code>  app::routes('*');
  <h3>Sample for everything</h3> The index.php file has the "test" route registered, and that test.php route a call for each verb which you could use as a starting point for your own services.
</code></pre>


GP routing – WP compatible REST API

Allows developers to create REST-ish API's that have access to all of Wordpress and its plug-ins objects.

Dave McHale

Tang Rufus

<p>The most comprehensive plugin for controlling access to the WordPress REST API!</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>


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!

GP routing – WP compatible REST API vs Disable REST API