Update README for API change

README.md

@@ -32,12 +32,12 @@ This example call to the service using `curl` will cause the puppet master to si
 configuration file called "environment" to be run as well. It will also submit some HTTP authentication credentials
 using the digest method.
 ```bash
-$ curl http://puppet.my.org:8240/provision -d hostname=newnode.my.org -d tasks=cert,environment \
+$ curl http://puppet.my.org:8240/provision -d hostname=newnode.my.org -d tasks=cert-sign,environment \
 --digest --user provision-user:SomeSuperSecretPassword  
 ```
 
 ## Requirements
-The service is a statically-linked binary, so external dependencies / environmental requirements are minimal.
+The service is pretty much a statically-linked binary, so external dependencies / environmental requirements are minimal.
 That said,
   * Testing is occurring only on Linux. YMMV on Windows; feel free to provide feedback if you use this
     software in a Windows environment.
@@ -58,7 +58,7 @@ and `go install` it.
 ## Starting and Stopping
 The process can typically be started simply by executing it with no arguments. It should be run as the same
 user that runs your puppet master server, user `puppet` on standard installations.  
-It does not daemonize, so write initscripts accordingly.
+It does not daemonize, so write initscripts / systemd services accordingly.
 
 The process should shut down cleanly in response to SIGTERMs.
 
@@ -70,16 +70,15 @@ The process should shut down cleanly in response to SIGTERMs.
 <table border="1">
   <tr><th>Field</th><th>Required?</th><th>Example</th><th>Description</th></tr>
   <tr><td>hostname</td><td>required</td><td>foo.bar.com</td><td>The name of the host to be provisioned, as it will identify itself to puppet.</td></tr>
-  <tr><td>tasks</td><td>required</td><td>cert,environment</td><td>Comma-separated list of provisioning operations to perform. Valid operations are the `Name`s defined in the `GenericExecTasks` configuration section, plus the special built-in task name `cert` to cause client certificate signing.</td></tr>
-  <tr><td>waits</td><td>optional</td><td>environment</td><td>Comma-separated list of provisioning operations to wait for before the response is sent back. If you need to know the outcome of a provisioning operation, add it to this list and its results will be included in the response.</td></tr>  
-  <tr><td>cert-revoke</td><td>optional</td><td>true</td><td>If set, any existing certificates for the same hostname will be revoked to enable successful signing of a new CSR for this hostname.</td></tr>
+  <tr><td>tasks</td><td>required</td><td>cert-sign,cert-revoke,environment</td><td>Comma-separated list of provisioning operations to perform. Valid operations are the `Name`s defined in the `GenericExecTasks` configuration section, plus these special built-in task names:<ul><li>`cert-sign`: causes client certificate to be signed.</li><li>`cert-revoke`: causes any existing client certificate for same hostname to be revoked.</li></ul></td></tr>
+  <tr><td>waits</td><td>optional</td><td>cert-revoke,environment</td><td>Comma-separated list of provisioning operations to wait for before the response is sent back. If you need to know the outcome of a provisioning operation, add it to this list and its results will be included in the response.</td></tr>  
 </table>
 
-Requested tasks are assumed to be independent of each other and are run concurrently. If you need
-tasks to be run in a particular order, call the API multiple times with `waits` on the earlier tasks.
+If you configure `GenericExecTasks`, you may also POST other fields and use them in the invocation template as a means
+to pass data to your task.
 
 #### Response
-**Content-Type: application/json**
+**Content-Type: application/json**  
 A json object containing a key matching each of the tasks requested. The value of each task key is an
 object with the following values:
 <table border="1">