diff options
| -rw-r--r-- | README.org | 35 |
1 files changed, 19 insertions, 16 deletions
@@ -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 |