I'm obviously misunderstanding something really obvious here, and it would help me out hugely to have an explanation as to the behaviour I'm witnessing with a specific nested routing definition.
Here's some example code:
val ordersRoute =
pathPrefix("orders") {
pathEnd {
get {
println("GET /orders")
complete("GET /orders")
} ~
post {
println("POST /orders")
complete("POST /orders")
}
} ~
pathPrefix(Segment) { orderId =>
pathEnd {
get {
println("GET /orders/{order_id}")
complete("GET /orders/{order_id}")
}
} ~
pathPrefix("items") {
pathEnd {
get {
println("GET /orders/{order_id}/items")
complete("GET /orders/{order_id}/items")
} ~
post {
println("POST /orders/{order_id}/items")
complete("POST /orders/{order_id}/items")
}
} ~
path(Segment) { itemId =>
put {
println("PUT /orders/{order_id}/items/{item_id}")
complete("PUT /orders/{order_id}/items/{item_id}")
}
}
}
}
}
And, here are the key things I don't understand about the behaviour I'm witnessing:
- The printlns for the /orders route, for both GET and POST, get executed on boot and not during execution of the route
- The printlns for all other routes do not get executed on boot and only during execution of the route
- If I execute a POST request on /orders/<some_id>/items, it seems to execute all three paths, GET /orders/<some_id>, GET /orders/<some_id>/items and POST /orders/<some_id>/items
Especially confusing is the last point - it would appear that paths are being executed even when the request does not match - e.g. why is the handler for GET /orders/<some_id>/items being executed when the request coming in is a POST? Surely the whole point here is that the get { ... } directive should reject if the request method is not a GET?
But I'm also intrigued about the first point with regard the printlns being executed on boot in the first two cases, but not in the remaining cases.
I'm assuming I've got a fundamental misunderstanding about something here that could be cleared up very quickly?!
Thanks for any help/advice anyone can share.
Cheers,
Andrew