I think perhaps your mistaking the same mistake I did when I first picked
up Akka HTTP coming from a background with Jersey.
What I wanted to do - was nest paths inside of each other thinking:
path("v1") {
path("orders") {whatever}
path("customers") {whatever}
}
Would be the perfect syntax for setting up the 2 paths:
/v1/orders/...
/v1/customers/...
In a really easy to comprehend and sensible manner. EG Each sub path prefix
only really matching an individual segment like how your speaking.
In practice it appears that it works more as though each nested path does
not operate on the remaining unmatched path - but actually the whole url.
In a sense the above code is saying match paths that both look like: START
- /v1/ - END AND START - /orders/ - END. Obviously an impossible situation.
So what we do is simply enumerate the paths we want to match for (rather
than nest them) and use PathMatcher DSL to enable us to avoid any real
overhead to the code for this. In the end it's just as readable (If not a
little bit more so since your enumerating explicitly your matching
possibilities rather than nesting them).
http://doc.akka.io/docs/akka-http/10.0.4/scala/http/routing-dsl/path-matchers.html#pathmatcher-dsl
What does this look like? (In Java)
public static final String PATH_ORDERS = "orders";
public static final String PATH_VERSION = "v2";
private static final PathMatcher1<UUID> PATH_PARAM_UUID =
PathMatchers.uuidSegment();
route(
path(
PathMatchers
.segment(PATH_VERSION)
.slash(PATH_ORDERS),
() -> put(...-> createOrder())
),
path(
PathMatchers
.segment(PATH_VERSION)
.slash(PATH_ORDERS)
.slash(PATH_PARAM_UUID),
orderId -> route(
post(...->changeOrderStatus(orderId),
get(...->getOrder(orderId)
)
))
Code above representative only and in an older version of Akka HTTP but
much the same as current. The - ...-> syntax used to highlight what methods
like getOrder are doing (They are just returning Routes which further limit
down by GET/POST/similar). Sure we could have made it a lot nicer by
defining and reusing:
PathMatcher0 VERSION = PathMatchers.segment(PATH_VERSION)
One practices we found that worked - do the splitting by HTTP method
(GET/POST/PUT) down at the lowest level. Often you have a URL like
/v1/orders that accepts GET, PUT and POST and then you can nest all 3
options under one path matcher.
Can you do a fully nesting style like v1/ { orders, customers } ? Probably
using the wildcards like you suggest, but I could never get it to work like
that (I tried a lot) and i'm not sure if its designed for that use case.
Frankly I kind of ended up preferring the enumerated style and found it
easier to manage than Jerseys nested api styling.
If you checkout some of the Akka seed projects using Akka HTTP they
probably show better examples in your language of preference too :)
http://www.lightbend.com/community/core-tools/activator-and-sbt
Activator is amazing for finding feature fledged examples of how to use
things.
On Friday, 17 March 2017 11:25:09 UTC, Alan Burlison wrote:
>
> I'm sure I must be missing something here because I can't believe path
> matching in Akka HTTP could be broken in the way it seems to be, because
> it would be unusable for anything other than toy applications if it was:
>
> I'm composing route handing from a top-level handler and sub-handlers
> like this:
>
> pathPrefix("root") {
> concat(
> pathPrefix("service1") { service1.route },
> pathPrefix("service2") { service2.route }
> )
> }
>
> where service1.route etc returns the sub-route for the associated
> sub-tree. That works fine with a path of say "/root/service1", but it
> *also* matches "/rootnotroot/service1", because pathPrefix() just
> matches any arbitrary string prefix and not a full path segment. And if
> I use path() instead of pathPrefix() it tries to match the entire
> remaining path. What I'm looking for is something along the lines of
> segment() where that fully matches just the next path segment and leaves
> the remaining path to be matched by inner routes, but there doesn't seem
> to be such a thing.
>
> What am I missing?
>
> Thanks,
>
> --
> Alan Burlison
> --
>
--
Notice: This email is confidential and may contain copyright material of
members of the Ocado Group. Opinions and views expressed in this message
may not necessarily reflect the opinions and views of the members of the
Ocado Group.
If you are not the intended recipient, please notify us immediately and
delete all copies of this message. Please note that it is your
responsibility to scan this message for viruses.
Fetch and Sizzle are trading names of Speciality Stores Limited and Fabled
is a trading name of Marie Claire Beauty Limited, both members of the Ocado
Group.
References to the “Ocado Group” are to Ocado Group plc (registered in
England and Wales with number 7098618) and its subsidiary undertakings (as
that expression is defined in the Companies Act 2006) from time to time.
The registered office of Ocado Group plc is Titan Court, 3 Bishops Square,
Hatfield Business Park, Hatfield, Herts. AL10 9NE.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
