Takes design doesn't work with REST architectural style

[piotrkot]

According to the RESTful API design web services should be specialized around resources and their granularization e.g.
PUT /companies/{id}/locations/{id}/employees/{id}

Building RESTful API services using Takes have problems:

• One has to heavily use TkRegex, which cannot be passed to TkAuth, TkSecure, TkMethods, etc. (just to name a few). TkRegex can currently be only used in FkRegex, drastically limiting the flexibility of use.
  Do you think adding (many) new constructors containing TkRegex is a good design?
• There is a class RqHref which let access all query parameters. One could create a similar class, say, RqPath which could let access all the path parameters with a matcher (similarly to RqRegex). But then we expose ourselves to the errors with class compositions, i.e. assuming the path /companies/{id}/locations/{id}/employees/{id}, a class TkCrudEmployees would only work if it's inside the TkCrudLocations which is inside the TkCrudCompanies. Do you think it's a good design?
• Or maybe you believe the RESTful API design being a state transfer and close to CRUD operations is not aligned with the object-oriented paradigm of the proper web services' design? In such case it would be nice to share new ideas.

[laeubi]

I recently build a very simple REST interface, and actually one can combine TkRegex with TkMethods even though its not very obvious, but in the end fits quite well into the REST patterns, you need to do the following:

1. Create a Map<String, List<FkRegex>> the key is the method (e.g GET/POST/PUT/...) and the list is FkRegex with a TkRegex that maps your operations for that method
2. now for each entry in the map create a FkMethods (with key) and pass it a TkFork with the list of operations (value) and store this in a List<FkMethods>
3. now create a final TkFork that gets the List<FkMethods> and pass it for example to BkBasic

Now one could think about replace FkRegex with something that understands the path syntax (e.g FkPath) and instead of a regex passes a Map<String, String> with for example a TkPath#params() or similar.

The only drawback is that TkFork will choose the first matching, while for REST one wants to match the most specific one maybe but this could be solved by a custom TkRest or similar that implements such kind of delegation model...