Update: Readme

1 files changed, 19 insertions, 16 deletions

diff --git a/README.org b/README.org
index 518f60d..e00eb8c 100644
--- a/README.org
+++ b/README.org
@@ -66,18 +66,17 @@ OOPyness is an advantage. Object orientation allows one to:
   endponit classes. Whole regions of a site or API can easly be
   extended or modified.
 
-- ~ENDPOINT~ itself can be sublcassed for special endpoint definition
-  logic. E.g. ensuring a route prefix without having to type it each
-  time can be acheived by specializing ~instantiate-instance~ on a
-  subclass of ~ENDPOINT~.
-
-- You can use the reified endpoints to automatically generate nice
-  documentation. (Less than nice documentation is already provided via
-  the function ~weekend:print-all-route-documentation~.)
+- You can use the reified endpoints to automatically for your
+  API. See the function ~weekend:print-all-route-documentation~.
 
 - Similarly, you can automatically generate API client code for your
   langauge of choice.
 
+- ~ENDPOINT~ itself can be sublcassed for special endpoint definition
+  logic. E.g. ensuring a route prefix without having to type it each
+  time can be acheived by specializing ~instantiate-instance~ on a
+  subclass of ~ENDPOINT~ to alter the ~:route-parts~.
+
 
 ** Defining Routes
 
@@ -111,25 +110,29 @@ E.g
 #+end_src
 
 
-In ~:route-parts~ there are four parts, two match groups. The
-~:extractors~ slot has two extractor specs.
+In ~:route-parts~ there are four parts. Two of those parts are match
+groups: =([0-9]+)= and =(blah|nah)=. The ~:extractors~ slot has two
+extractor specs.
 
-The parts will be combined into a regular expression:
+The route parts will be combined into a regular expression:
 ="^/foo/([0-9]+)/bar/(blah|nah)$"=
 
 The first match group matches a string of digits. That string is
 parsed by ~parse-integer~ and then supplied to the ~:foo-id~ initarg.
 
 The second match group matches either ~"blah"~ or ~"nah"~ and is
-passed as-is tot he ~:bar-val~ initarg.
+passed as-is to the ~:bar-val~ initarg.
 
-This class would handle the route =GET /foo/322/bar/nah= for example.
+This class would handle the route =GET /foo/322/bar/nah= for
+example. It would not handle =POST /foo/322/bar/nah= nor =GET
+/foo/xxx/bar/nah=. In both latter caes a 404 would be returned to the
+client.
 
 You might be asking yourself "why not just write the regex as a
-string?"  Well thats a good question. You can actually do that (dig
+string?"  Well that's a good question. You *can* actually do that (dig
 into the ~endpoint~ metaclass yourself to see how), but the reason I
-prefer ~:route-parts~ is to allow for defining your regex pattern
-groups outside of the route as module parameters. See
+prefer ~:route-parts~ is that it allows for defining reusable regex
+patterns and storing them in global parameters. See
 examples/dice-roller.lisp.
 
 ** Passing Values in Query Params