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.

Evan Herman

Tracy Levesque

Code Parrots

yikesitskevin

karmadharma

jpowersdev

<p>WP REST API Controller allows admins to toggle the visibility of, and customize the endpoints for, all core and <em>custom</em> post types and taxonomies within WordPress with an easy-to-use graphical interface. Additionally, you can tweak visibility and customize the meta data attached to the API response.</p>
<blockquote>
<p><strong>Note:</strong> This plugin requires WordPress Version 4.7 or later to work.</p>
</blockquote>
<p><strong>Features:</strong></p>
<ul>
<li>Enable/Disable REST API endpoints for post types and taxonomies.</li>
<li>Enable/Disable post type/taxonomy meta data (add or remove meta fields from API requests).</li>
<li>Rename post type/taxonomy base endpoints.</li>
<li>Rename post type/taxonomy meta data names in API requests so they are more user friendly.</li>
<li>Manipulate and control post types/taxonomies and their data created by third party plugins and themes.</li>
<li>Granular control of API responses without writing a single line of PHP code.</li>
<li>Filters included to alter and extend default functionality.</li>
<li>Localized and ready for translations.</li>
</ul>


WP REST API Controller

This plugin is amazing, taking a complicated thing and making it easy to accomplish. Thanks!!

I wish I could give you 10 stars

Enable a UI to toggle visibility and customize properties in WP REST API requests.

GP routing – WP compatible REST API vs WP REST API Controller