aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorcolin <colin@cicadas.surf>2024-05-12 06:34:02 -0700
committercolin <colin@cicadas.surf>2024-05-12 06:34:02 -0700
commitb76fa9a4c9c5f4b0e4763e5e807df9e715f74d90 (patch)
tree0db19b2e29d123e0c60bdc08175b8557624a59a0
parenta176342ae03af520bbc27a7860f586f6c73b58a2 (diff)
Update: Readme
-rw-r--r--README.org35
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