1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
* WEEKEND: another HTTP endpoint building library
With ~WEEKEND~, endpoints are classes defined with the metaclass
~endpoint~.
The ~endpoint~ metaclass provides a number of class-level slots which
specify the HTTP method and the route that the class is meant to
handle.
Compiling the endpoint class automatically builds and registers a
hunchentoot handler. Recompiling the class removes the old handler and
builds a new one.
Instance slots of an ~endpoint~ class hold data necessary to process
the request. If a slot is defined with an ~:initarg~, then that slot's
value is meant to be supplied by the HTTP request, be through embedded
"route variables", query parameters, or fields in a structured request
body.
Any slot defined without an ~:initarg~ is meant to have its
value supplied by some stage in the handler protocol.
The handler protocol is used to control the handling of requests. All
endpoint classes are required to specialize the ~weekend:handle~
method. Optionally they may also specialize the ~weekend:authenticate~
and ~weekend:authorize~ methods.
Before ~handle~ is called, ~authorize~ is called, and before
~authorize~ is called, ~authenticate~ is called. If either
~authenticate~ or ~authorize~ return ~NIL~, then the appropriate HTTP
error is returned to the client. Otherwise ~handle~ is assumed to have
all it needs to produce the content to be returned to the requesting
client.
** Examples
See [[./examples][examples]] for a few examples.
** Advantages of the Approach
OOPyness is an advantage. For example: you can easily recycle
authentication and authorization by creating mix-in classes on which
~authorize~ and ~authenticate~ are specialized. Anytime you want to
add a new endpoint that must be authorized in a particular way, it is
as easy as adding your mix-in to your new endpoint's superclasses.
The same thing applies to establishing and dis-establishing database
connections - you simply specialize ~handle~'s ~:around~ method, or
~:before~ and ~:after~ methods, on your endpoint class.
If you want special processing on your endpoint classes themselves,
you can sublcass the ~endpoint~ metaclass and specialize
~intstantiate-instance~ methods.
For example, if you would prefer every endpoint to be be prefixed by a
particular route string, you can transform the ~route-parts~ field
before they are processed by ~endpoint~'s ~instantiate-instance~
method.
** Disadvantages of the Approach
WEEKEND can be be a little verbose. You are free to define your own
class-defining macros.
This version of weekend is strongly tied to Hunchentoot.
|
