You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+16-25Lines changed: 16 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,13 @@ You can use `Group` to help organize your routes and cut down on the repetitiven
27
27
app.register {
28
28
Group("api", "v1") {
29
29
Group("movies") {
30
+
GET { ... }
30
31
GET("latest") { ... }
31
32
GET("popular") { ... }
32
33
GET(":movie") { ... }
33
34
}
34
35
Group("books") {
36
+
GET { ... }
35
37
GET("new") { ... }
36
38
GET("trending") { ... }
37
39
GET(":book") { ... }
@@ -68,17 +70,16 @@ If you have more than one middleware... no worries, `.middleware(_:)` accepts a
68
70
```swift
69
71
Group {
70
72
GET("foo") { ... }
71
-
Group {
72
-
GET("bar") { ... }
73
-
}
74
-
.middleware(Authentication(), Validator())
73
+
GET("bar") { ... }
74
+
.middleware(Authentication(), Validator())
75
+
.middleware(Reporter())
75
76
}
76
77
.middleware(Logging())
77
78
```
78
79
79
-
Remember that order matters here. Incoming requests will always execute middleware from top to bottom. So in the above example, the order of an incoming request would be as follows ➡️ `Logging`, `Authentication`, `Validator`. Outgoing respones will always execute middleware in the reverse order. ➡️ `Validator`, `Authentication`, `Logging`.
80
+
Remember that order matters here. Incoming requests will always execute middleware from the top of the tree to the bottom. So in the above example, the order of an incoming request would be as follows ➡️ `Logging`, `Reporter`, `Authentication`, `Validator`. Outgoing respones will always execute middleware in the reverse order. ➡️ `Validator`, `Authentication`, `Reporter`, `Logging`.
80
81
81
-
### Making Custom Route Components
82
+
### Custom Route Components
82
83
83
84
Often times, as your routes grow, a single large definition can become unwieldly and cumbersome to read and update. Organization of routes can be straightforward with `@RouteBuilder`
84
85
@@ -168,7 +169,6 @@ app.register {
168
169
169
170
For existing vapor applications, it may be unreasonable or unwieldly to rewrite your entire routing stack in one go. You can start with replacing smaller sections of your route definitions by registering a `RouteComponent` on any `RoutesBuilder` in your application.
170
171
171
-
172
172
```swift
173
173
let users = app.grouped("users")
174
174
users.get(":user") { ... }
@@ -182,25 +182,16 @@ books.register {
182
182
}
183
183
```
184
184
185
-
### RouteModifiers
186
-
187
-
- Currently undocumented.
185
+
### Route Metadata
188
186
189
-
## TODO
190
-
191
-
-[Confirmed] Implement Websocket support
192
-
-[Confirmed] Handle routes at the root of a RouteComponent.
187
+
Vapor supports adding metadata to your routes. To add your own metadata to a route within a `@RouteBuilder`, make use of either the `.description(_:)` modifier or the `.userInfo(key:value:)` modifier.
0 commit comments