microcipcip

Vue 2.0 boilerplate for ProcessWire 3.0

Recommended Posts

Hi, I have created a site profile that shows how to integrate ProcessWire 3.0 with Vue 2.0. See repository here.

 

How this site profile works

This ProcessWire site profile is loosely based on the REST API tutorial by @gebeer. Here are the most important steps to reproduce it:

 

Admin settings

  • Create an api template with default settings and just the title field assigned to it. Refer to @gebeer tutorial for further details

  • Create a pages and nav templates with just the title field, for both template tick “Allow URL Segments” in the “URLs” tab (see attachment)

  • Create a home template, this is going to be the single php file that will load your Vue SPA. Assign this template to the root of your website

  • Any other template you create should have the “Alternate Template Filename” field in the “Files” tab set as home (see attachment), in this way if a user enter the website from any url that is not the root, ProcessWire will always redirect to the home template, Vue router will handle the url and call the right data through the REST API

  • Under the root, create an api page and assign the api template to it (you can set “hidden” to this page so doesn't show up in the menu)

  • Under the api page, create the pages nav and pages (see attachment), and assign the templates nav and pages to them. Now you have the www.sitename.com/api/pages and www.sitename.com/api/nav urls that you can use to fetch the JSON data

 

PHP template setup

  • In the templates folder, create home.php file and leave it empty, the HTML will be generated by webpack

  • Now create pages.php and nav.php files. On these files is where we return the JSON data, based on the right url segment. Again, refer to @gebeer tutorial for further details on this matter. Note that I wrote a PageFields class that I use on these templates to fetch ProcessWire fields. The fields that are supported are text, textarea, repeater, img. Other fields may work but I haven't tested them. See the REST API setup for further details about how to use the PageFields class


REST API setup

You can decide what fields are included and what fields are excluded by passing a configuration array to the PageFields class. You can find here a list of the available configuration settings. See examples below.

 

  • Show only selected core fields:
    $pageFields = new PageFields($p, [
      'fld_core_included' => ['url', 'httpUrl', 'template']
    ]);

     

  • Show no global fields, and only selected custom fields:

    $pageFields = new PageFields($p, [
      'fld_core_included' => [],
      'fld_include_all' => false,
      'fld_included' => ['title', 'gallery'],
    ]);

     

  • On a gallery image field, hide breakpoint listing and show only httpUrl field:

    $pageFields = new PageFields($p, [
      'img_fld_overrides' => [
        'gallery' => [ 'fields' => ['httpUrl'], 'bp_list' => false ]
      ],
    ]);

     

Webpack setup

The most important file of all Webpack setup is config/index.js. On line 33 you need to provide your domain name so that Webpack can proxy the ProcessWire REST API to the Webpack dev server. Without this you wouldn't be able to take advandage of the Webpack hot module replacement feature which allows you to reload a vue module without refreshing the page, it also allows you to keep the state of the app.

 

Notes

My REST API may have bugs, this is just an example of an integration with ProcessWire, I suggest you either build your own REST API or use the awesome GraphQL module by @Nurguly Ashyrov.


Todo

Replace REST API with the GraphQL module. This requires vue-apollo, the Apollo/GraphQL integration with Vue, and vue-supply for integration with Vuex.

 

 

  • Like 19

Share this post


Link to post
Share on other sites

Cool stuff, @microcipcip!

Please do write a tutorial when you have time. I am sure it will be useful to many of us in the community. Surely it will be for me :rolleyes:.

It seems like your boilerplate is not in a site profile format. Is there a reason for that? If not, consider using it, as it is a common way to distribute site boilerplate code and could make your work easier to reuse for PW people.

  • Like 2

Share this post


Link to post
Share on other sites

Hey, @microcipcip! I actually do not know if it is possible to do with the profile exporter via setting . Though I am sure it should be.

Removing node_modules should be easy - you can do it before the export (or temporary prefix the folder with a dot :rolleyes:). Adding .config type files is probably only possible the way you suggest.

But as I said I think all those things should be eventually possible to do with the module options, as it is very powerful way to share one's work in PW. Please list the issues you cannot overcome in the module support board or even better on github.

Edit: Seems like a .file issue is already present. I am going to add my voice to it. Please do too if you think it deserves it.

Edited by Ivan Gretsky
  • Like 2

Share this post


Link to post
Share on other sites

I have edited the github repository, now ProcessVue is a site profile and you can install it easily. Just note that the REST API may have bugs...I don't even remember how it works :rolleyes:

  • Like 5

Share this post


Link to post
Share on other sites

Just wanted to say thanks for your work. You and @Nurguly Ashyrov are the people with projects who made me interested in ProcessWire. This outdated website doesn't give the best impression, but after a few FAQs and your threads, man am I interested. 

  • Like 4

Share this post


Link to post
Share on other sites

I am glad that this project is helping ProcessWire getting more devs on board :). I just want to say that I wouldn't have been able to finish ProcessVue if it wasn't for the amazing ProcessWire community. I believe that the community truly is the biggest selling point for new users (like me). Before trying ProcessWire I used OctoberCMS for a while but when I was stuck I got 0 support from the forums, so...althought the CMS is based on the amazing Laravel framework, I just left!

I think that ProcessWire is extremely powerful and flexible and with time will become the tool of choice for frontend developers, the new GraphQL module will also help on this direction. Droves of frontend developers are looking for a CMS like this, they just don't know it exists! The usual keywords they use when looking for a SPAs CMS is "Decoupled CMS" or "Headless CMS", and I believe that that's exactly what ProcessWire is for!

Some frontend developers prefer to use NodeJS but I think that Node is just too young and is not stable enough, the learning curve is huge if you need it for a non trivial project, and the worst thing of all is that after two weeks ANY js tool you may have used is outdated. See for example how Angular has been replaced with React or Vue, and Gulp with Webpack. That doesn't mean that I am against improvements in this regard, I just feel that it's just too much for us poor frontend devs to cope with! ProcessWire is stable, easy to use and won't change API every week.

BTW, after that I migrate ProcessVue to GraphQL I am also planning to add Auth0 login integration with JWT, as I think that login/signup is a common feature in SPAs. I am sure I'll have to annoy @Nurguly Ashyrov and the rest of ProcessWire community for getting it in sync with ProcessWire users, but the result should be quite useful :)

  • Like 11

Share this post


Link to post
Share on other sites

Hi @microcipcip - thanks for a really great commentary on PW, what frontend devs are looking for, and how PW can fit those needs.

I am really excited to see your integration of GraphQL into your ProcessVue site profile - definitely planning on using it on an upcoming project.

Thanks again for all your great work on this.

  • Like 4

Share this post


Link to post
Share on other sites

Thanks @thomasaull :) ATM I am waiting for GraphQL module support for RepeaterFields before I integrate it in processvue. I'll implement the JWT login later on because I haven't used it before so I need to learn how it works, but it is definitely on my list of things to do. I don't know how JWT should integrate with GraphQL too, I'll probably ask @Nurguly Ashyrov if he has any idea of how I should integrate it.

There's also the problem that GraphQL allows you way too much freedom on what kind of query you can perform on the client, to prevent that I've got to implement persisted queries.

  • Like 3

Share this post


Link to post
Share on other sites

Sounds good. I recently read some stuff about JWT, maybe I'm gonna give it a shot trying to implement it with a default REST Api… Not sure if I got the time though…

This articles has some overview info: https://www.sitepoint.com/php-authorization-jwt-json-web-tokens/
And this is a library for doing the stuff in PHP: https://github.com/firebase/php-jwt

  • Like 2

Share this post


Link to post
Share on other sites

Thanks @thomasaull that would be great! There is an amazing new tutorial https://auth0.com/blog/vuejs2-authentication-tutorial/ if you don't mind having the users saved on Auth0. After all, Auth0 is the company behind the JWT website so they should implement it properly and you can obviosuly still keep all users in sync with ProcessWire db. But regarding Rest API I'd rather use GraphQL instead because that seems more flexible.

  • Like 2

Share this post


Link to post
Share on other sites

Thx for the hint to this tutorial @microcipcip and sry for my late reply. No progress so far… 🙈 Storing the users at an external server is no option in this case, but maybe there's usefull stuff in there anyway ;)

GraphQL seems to be really nice, but I'm not sure if it's to early to adopt it. If, the way to go seems to use the Vue-Apollo: https://github.com/Akryum/vue-apollo
Any other pointers from your side? :)

Share this post


Link to post
Share on other sites
On 30/05/2017 at 11:27 AM, thomasaull said:

Any other pointers from your side? :)

No, whichever way you choose I think that a login process with Vue will be greately appreciated by the community :)

Share this post


Link to post
Share on other sites

I get an error with a clean install when I run "npm i"

Error: Cannot find module '/home/goac/mywebsitehere/site/templates/client/node_modules/node-sass/scripts/install.js'
    at Function.Module._resolveFilename (module.js:469:15)

 

Share this post


Link to post
Share on other sites
17 hours ago, joer80 said:

I get an error with a clean install when I run "npm i"


Error: Cannot find module '/home/goac/mywebsitehere/site/templates/client/node_modules/node-sass/scripts/install.js'
    at Function.Module._resolveFilename (module.js:469:15)

 

That is unlikely an error with the ProcessVue template. Are you using Ubuntu? I found this thread with a similar problem where they fixed it by using the "--unsafe-perm" flag during "npm i", so basically you'd have to run it with this command: "npm --unsafe-perm i". Edit: from that thread it seems that the user you're using may not have the right write permissions.

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, microcipcip said:

That is unlikely an error with the ProcessVue template. Are you using Ubuntu? I found this thread with a similar problem where they fixed it by using the "--unsafe-perm" flag during "npm i", so basically you'd have to run it with this command: "npm --unsafe-perm i". Edit: from that thread it seems that the user you're using may not have the right write permissions.

 

When I login as root and run npm i it says:

npm WARN prefer global node-gyp@3.6.2 should be installed with -g

> node-sass@4.5.3 install /home/goac/vue.greggorrauto.com/site/templates/client/node_modules/node-sass
> node scripts/install.js

module.js:471
    throw err;
    ^

Error: Cannot find module '/home/goac/websitehere/site/templates/client/node_modules/node-sass/scripts/install.js'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:389:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:504:3

 

On Centos

Share this post


Link to post
Share on other sites

Is this thread still active? I have developed a couple of Processwire sites, and I use Npm, Stylus, Webpack, and Wamp64 for development. However, I cannot make sense of your Github installation directions. Here is my first stop point:

Quote

Load the URL to your ProcessWire installation in your browser to initiate the installer. Select the "ProcessVue" profile from the dropdown when prompted to do so. The installer will take care of the rest.

My browser loads my Processwire installation from only two places, my site directory, or the PW admin site. How do you get it to load somewhere else? What "dropdown"?

I am relatively new to PW. I like it, but I must be missing something. A lot of the docs are like " How to draw an owl: First draw two circles. Then draw the rest of the owl. Congratulations."

Share this post


Link to post
Share on other sites
1 hour ago, rocket said:

Select the "ProcessVue" profile from the dropdown when prompted to do so. The installer will take care of the rest.

He means the initial setup & configuration. Even before you set up your database. Like this one

1.png.5a1122bc7640b814b8d27a585170f850.png

install2.jpg.043fb0c9f39874eeee91bba8c1dfdb89.jpg

https://processwire.com/docs/tutorials/installation-moving-and-troubleshooting/page4

 

Share this post


Link to post
Share on other sites

Thanks. I thought the OP was talking about some self-installer in the site-processvue folder. I didn't realize it required a whole re-install of Processwire.

Share this post


Link to post
Share on other sites
On 08/09/2017 at 2:41 PM, rocket said:

Thanks. I thought the OP was talking about some self-installer in the site-processvue folder. I didn't realize it required a whole re-install of Processwire.

AFAIK this is the way ProcessWire theme install works. If you want you can install it manually but it will require more time, you have to follow the instructions in the first post of this thread.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By gebeer
      In this tutorial I will cover how to use clsource's REST Helper classes to create a RESTful API endpoint within a PW-powered site and how to connect to it from the outside world with a REST client. This is a quite lengthy tutorial. If you follow all along and make it through to the end, you should get both, a working REST API with ProcessWire and hopefully some more basic understanding how these APIs work.

      As always with PW, there are many ways you could do this. My way of implementing it and the code examples are loosely based on a real world project that I am working on.

      Also, this is the first tutorial I am writing, so please bear with me if my instructions and examples are not that clear to understand. And please let me know if something is missing or could be made more clear.

      The steps covered:
      create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed at) copy and save the REST Helper classes to your site create a template file and write some logic to receive and process data through our endpoint and send data back to the REST client test the whole setup with a Browser REST Client Addon I will not go into fundamentals and technical details on how RESTful APis are supposed to work. I assume that you have already read up on that and have a basic understanding of the principles behind that technology. Some helpful resources to brush up your knowledge:
      https://en.wikipedia.org/wiki/Representational_state_transfer
      http://www.restapitutorial.com/lessons/whatisrest.html

      The complete pages.php template is attached to this post for copy/paste.

      Lets get started.

      1. create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed)
      First we need to create some templates and pages in the PW backend to make our REST API accessible from the outside world through an URL (API endpoint).
      In my example this URL will be: https://mysite.dev/api/pages/
      Note the "https" part. While this is not mandatory, I strongly recommend having your API endpoint use the https protocol, for security reasons.
      Further down in step 3 we will use this URL to create new pages / update and get data of existing pages.
       
      Go to your PW test site admin and:
      create 2 new templates: one is called "api", the other one "pages". For a start, they both have only a title field assigned. Just create the templates. We will create the corresponding files later, when we need them. enable "allow URL segments" for the "pages" template. We will need this later to access data sent by the requests from the client. in the Files tab of the "pages" template check "Disable automatic append of file: _main.php" create a new page under the home page with title, name and template "api" and set it to hidden create a child page for the "api" page with title, name and template "pages" The pagetree should look somewhat like this:

      Ok, now we're all set up for creating our API endpoint. If you browse to https://mysite.dev/api/pages/ you will most likely get a 404 error or will be redirected to your home page as we do not have a template file yet for the "pages" template. We will add that later in step 3.

      2. copy and save the REST Helper classes to your site
      I have the REST Helper class sitting in site/templates/inc/Rest.php and include it from there. You could save it in any other location within your site/templates folder.
      I forked clsource's original code to add basic HTTP authentication support. Click here to open my raw gist, copy the contents and save them to /site/templates/inc/Rest.php

      In the next step we will include this file to make the classes "Rest" and "Request" available to our template file.

      3. create a template file and write some logic to receive and process data through our endpoint and send data back to the client
      This will be the longest and most complex part of the tutorial. But I will try to present it in small, easy to follow chunks.

      Since we access our API at https://mysite.dev/api/pages/, we need to create a template file called "pages.php" for our "pages" template and save it to /site/templates/pages.php. Go ahead and create this file (if you're lazy, copy the attached file).

      Now right at the top of pages.php, we start with
      <?php require_once "./inc/Rest.php"; to include the REST Helper classes.

      Next, we initialize some variables that we will keep using later on
      // set vars with the default output $statuscode = 200; $response = []; $header = Rest\Header::mimeType('json'); 3.1 retrieve data with a GET request
      Now that we have the basics set up, we will next create the code for handling the easiest request type, a GET request. With the GET request we will ask the API to return data for an existing page. To let the API know which page it should return data for, we need to send the page id along with our request. I am attaching the page id as an url segment to the API endpoint. So the URL that the client will use to retrieve data for a page will look like: https://mysite.dev/api/pages/1234
      where 1234 is the unique page id.

      Add following code to pages.php


      // if we have an urlsegment and it is a numeric string we get data from or update an existing page: handle GET and PUT requests if($input->urlSegment1 && is_numeric($input->urlSegment1)) { $pageId = $input->urlSegment1; // GET request: get data from existing page if(Rest\Request::is('get')) { // get the page for given Id $p = $pages->get($pageId); if($p->id) { $pdata = ["id" => $pageId]; // array for storing page data with added page id $p->of(false); // set output formatting to false before retrieving page data // loop through the page fields and add their names and values to $pdata array foreach($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen) continue; $value = $p->get($field->name); $pdata[$field->name] = $field->type->sleepValue($p, $field, $value); } $response = $pdata; } else { //page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } else { // no url segment: handle POST requests } // render the response and body http_response_code($statuscode); header($header); echo json_encode($response); Lets brake this down:
      First we check for a numeric url segment which is our $pageId.
      Then the Rest Request class comes into play and checks what type of request is coming in from the client.
      For the GET request, we want to return all data that is stored for a page plus the page id. This is all good old PW API code.
      I am using the $pdata array to store all page data. Then I am handing this array over to the $response variable. This will be used further down to render the JSON response body.
      If the page does not exist, I am setting an error message for the $response and a status code 404 so the client will know what went wrong.
      The else statement will later hold our POST request handling.

      The last 3 lines of code are setting the header and status code for the response and print out the response body that is sent back to the client.

      You can now browse to https://mysite.dev/api/pages/1 where you should see a JSON string with field names and values of your home page. If you enter a page id which does not exist you should see a JSON string with the error message.

      Lets move on to updating pages through a PUT request

      3.2 update pages with a PUT request
      Since our API needs to know the id of the page we want to update, we again need to append an id to our endpoint url. In this example we will update the title and name of our homepage. So the request url will be: https://mysite.dev/api/pages/1.
      For the GET request above, anyone can connect to our API to retrieve page data. For the PUT request this is not a good idea. Thus we will add basic authentication so that only authorized clients can make updates. I use basic HTTP authentication with username and password. In combination with the https protocol this should be fairly safe.
      To set this up, we need an API key for the password and a username of our choosing. We add the API key in the PW backend:
      add a new text field "key" and assign it to the "api" template. edit the "api" page, enter your key and save. (I am using 123456 as key for this tutorial) Now add following code right after the if(Rest\Request::is('get')) {...} statement:
      // PUT request: update data of existing page if(Rest\Request::is('put')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // get the page for given Id $p = $pages->get($pageId); if($p->id) { $p->of(false); $p->title = $sanitizer->text($params["title"]); $p->name = $sanitizer->pageName($params["name"]); $p->save(); $response["success"] = "Page updated successfully"; } else { // page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } Breakdown:
      We check if the request from the client is a put request.
      All data that was sent by the client is available through the $params array.
      The $params array also includes $params["uname"] and $params["upass"] which hold our API user and key. We set API key and user and check if they match with the values that were sent by the client. If they don't match we store an error message to the response body and set the appropriate status code.
      If authentication went through ok, we get the page via PW API and update the values that were sent in the request body by the client.
      Then we put out a success message in the response body.
      If the page does not exist, we send the appropriate response message and status code, just like in the GET request example above.

      Now you might wonder how the client sends API user/key and new data for updating title and name. This is covered further down in step 4. If you want to test the PUT request right now, head down there and follow the instructions. If not, continue reading on how to setup a POST request for creating new pages.

      3.2 create new pages with a POST request
      Final part of the coding part is creating new pages through our API. For this to work we need to implement a POST request that sends all the data that we need for page creation.
      We will do this at our endpoint: https://mysite.dev/api/pages/

      Paste following code within the else statement that has the comment "// no url segment: handle POST requests":
      // POST request: create new page if(Rest\Request::is('post')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // create the new page $p = new Page(); $p->template = $sanitizer->text($params["template"]); $p->parent = $pages->get($sanitizer->text($params["parent"])); $p->name = $sanitizer->pageName($params["name"]); $p->title = $sanitizer->text($params["title"]); $p->save(); if($p->id) { $response["success"] = "Page created successfully"; $response["url"] = "https://mysite.dev/api/pages/{$p->id}"; } else { // page does not exist $response["error"] = "Something went wrong"; $statuscode = 404; // just as a dummy. Real error code depends on the type of error. } } } You already know what most of this code is doing (checking authorisation etc.). Here's what is new:
      We create a page through the PW API and assign it a template, a parent and basic content that was sent by the client.
      We check if the page has been saved and update our response body array with a success message and the URL that this page will be accessible at through the API for future requests. The client can store this URL for making GET or PUT requests to this page.

      If you're still reading, you have made it through the hard part of this tutorial. Congratulations. Having our code for reading, updating and creating pages, we now need a way to test the whole scenario. Read on to find out how this can be done.

      4. test the whole setup with a Browser REST Client Addon
      The link in the heading will take you to a place from which you can install the very useful RESTClient addon to your favorite browser. I am using it with Firefox which is still the dev browser of my choice.

      Open a RESTClient session by clicking the little red square icon in the browsers addon bar. The UI is pretty straightforward and intuitive to use.


      4.1 test the GET request
      Choose Method GET and fill in the URL to our endpoint.
      If you do not have a SSL setup for testing, just use http://yourrealtestdomain.dev/api/pages/1.
      If you happen to have a SSL test site with a self signed certificate, you need to point your browser to the URL https://yourrealtestdomain.dev/api/pages/ first in your test browser and add the security exception permanently. Otherwise RESTClient addon won't be able to retrieve data.
      If you have a test site with a 'real' SSL certificate, everything should be fine with using the https://... URL
      Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string with data of your page.

      now change the 1 i the URL to some id that does not exist in your site and hit send again. You should get a 404 Status Code in the Response Headers tab and an error message "{"error":"The page does not exist"}" in the Response Body (Raw) tab.
      If you get these results, congrats! The GET request is working.
      For further testing you can save this request through the top menu Favorite Requests->Save Current Request.

      4.1 test the PUT request
      Choose Method PUT and fill in the URL to our endpoint ending with 1 (http://yourrealtestdomain.dev/api/pages/1).
      In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request
      Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remember me" and hit Okay.
      You now should see Content-Type and Authorization headers in the "Headers" panel.

      Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. As I will update the home page for this example, my JSON reads
      { "title" : "Newhome", "name" : "newhome" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon.

      Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page updated successfully"}".

      Now go to the PW backend and check if title and name of your page have been updated. If yes, congrats again.

      4.2 test the POST request
      Choose Method POST and fill in the URL to our endpoint without any page id (http://yourrealtestdomain.dev/api/pages/).
      In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request
      Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remenber me" and hit Okay.
      You now should see Content-Type and Authorization headers in the "Headers" panel.

      Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. I will create a new page with template basic-page and parent /about/ for this example, my JSON reads
      { "template" : "basic-page", "parent" : "/about/", "title" : "New Page created through api", "name" : "newapipage" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon.

      Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page created successfully","url":"https:\/\/mysite.dev\/api\/pages\/1019"}".

      Now go to the PW backend and check if title and name of your page have been updated. If yes, you're awesome!

      Summary
      By now you have learned how to build a simple REST API with ProcessWire for exchanging data with mobile devices or other websites.

      Notes
      I tested this on a fresh PW 2.7.2 stable install with the minimal site profile and can confirm the code is working. If you experience any difficulties in getting this to work for you, let me know and I will try to help.
      There purposely is quite a lot of repetion in the example code to make it easier to digest. In real life code you might not want to use procedural coding style but rather separate repeating logic out into classes/methods.
      Also, in life applications you should do more sanity checks for the authentication of clients with the API / for the data that is delivered by the client requests and more solid error handling. I skipped these to make the code shorter.
      RESTful services are by definition stateless (sessionless). My implementation within PW still opens a new session for each request and I haven't found a way around that yet. If anyone can help out this would be much appreciated.
      And finally big thanks to clsource for putting the Rest.php classes together.
      pages.php.zip