I'm trying to use FastRoute based league/route: 4.5.1 package to handle routing on legacy project.
But old routes are case insensitive in static parts.
I.e, I have route /db/preferences/{id}, which can work with url like /db/Preferences/123 on legacy mode, but don't works with new routing cause it case sensitive.
Using midleware to lowercase all URI is not appropriate, because it affects dynamic segments.
How can I configure routing to handle such requests?
Maybe I need to implement DataGenerator class?
Please advice.
FYI, also posted question in #252
Related
I want to route requests in a way similar to how Python web.py or Python bottle does it.
With these frameworks you can simply add tags into the URL which can be used to pass parameters, eg:
#route('/api/part1/<tag1name>/part2/<tag2name>')
def handlerfunction(self, tag1name, tag2name):
CherryPy does have the popargs decorator, eg
#cherrypy.popargs('name')
However when there is more than one value encoded in the URI it becomes quite inconvenient to get them assigned to the parameters the right way.
In addition I want to be able to route based on the HTTP request method, as per the CherryPy MethodDispatcher.
The answer is to use a URL Route-mapping module such as "Routes". "Routes" is developed firstly for Pylons but does have support for CherryPy.
From the Documentation:
Routes is a Python re-implementation of the Rails routes system for mapping URLs to application actions, and conversely to generate URLs. Routes makes it easy to create pretty and concise URLs that are RESTful with little effort.
Routes allows conditional matching based on domain, cookies, HTTP method, or a custom function. Sub-domain support is built in. Routes comes with an extensive unit test suite.
After working through the documentation and getting it to work with CherryPy I will update this answer with some CherryPy specific implementation examples.
I'm building an application using Durandal 2. I want to define multiple routes using the same VM/View for different context.
Exemple :
/sectionA/:id/home using module ID /viewmodels/home
/sectionB/:id/home using module ID /viewmodels/home too
At first, sectionA and sectionB are meant to use the exact same VM and Views. But, eventually, they will be different. This is not where the issue is since when they'll be different, they'll have their very own VM and shared views (using MVC partials) which will work straight out the box.
The point is, for as long as the page are the same, we don't want to duplicate the VM and Views, generating a lot of garbage for nothing.
I tried the example shown above but that doesn't seems to be possible to do this. Whether the routes are different, it seems that the router cannot make the difference between the two routes and just throw a "route not found" exception although the route is defined in our route definition file.
So the question, is it possible to define two route, with obviously different routes definitions, but using the same moduleId?
If more details are require, don't hesitate to ask for clarifications.
Thanks! :)
I developed a REST API with Play 2.2.0. Some controllers expose GET methods, other expose POST methods with authentication etc...
I developed the client using Play as well but I have a problem. How can I avoid duplicating the model layer between both applications ?
In the server application, I have a Model Country(code, name).
In the client I am able to list countries and create new ones.
Currently, I have a class Country in both sides. When I get countries I deserialize them. The problem is that if I add a field in Country in the server, I have to maintain the client as well.
How can I share the Country entity between applications ?
PS : I don't want to create a dependency between the API and the client, as the client could have been developed with another language or framework
Thanks
This is not very specific to play framework but is more of a general question. You either create reusable representations of the data in your protocol (the actual data structures you send between your nodes) and get a tight coupling in representation and language. Many projects does it like this, since they know they will have the same platform throghout their architecture.
The other option is to duplicate all of or only the parts of parsing/generating that each part of the architecture needs, this way you get a looser coupling and can use any language in the different parts.
There are also some data protocols/tools that will have a representation in a protocol specific way and then can generate representations in various programming languages.
So as you see, it's all about pros and cons - neither solution is "the right way (tm)" to do this, you will have to think about your specific system/architecture and what pros are most valuable and what cons are most costly to you.
Well I suggest to send to the client a template of what they should display, on the client with js take advantage of js template frameworks, so you can tell to the client how can show them, dynamic... if they want to override them well... more job
We can call them Rest component oriented...
well suggestions :)
should works!
I'm trying to switch to ZF2 from ZF1. From what I've read about the new Zend\MVC\Router and the way it is configured, it looks like every single location should be described in ['router']['routes'] config key.
Is that really so? In ZF1 you could build a complex app with multiple locations and not have a single route described. I find it hard to believe, hopefully I am missing something.
Thanks!
The routing works in a similar way to ZF1. The config in the skeleton app includes a few example routes, one of which is a /:controller/:action route (line 42). So this is your out-of-the-box ZF1 style MVC route.
In ZF1, the framework adds a /:controller/:action and /:module/:controller/:action route for you (which you had to remove if you had some custom requirements). In ZF2 you have to define the routes yourself, but if you want the same setup as ZF1, the skeleton app setup works in the same way, just without the module prefix.
One of my co-workers is developing SOAP API for php application and he is wondering if CamelCaps names are some kind of convention for SOAP methods?
Our current API has lower_caps_and_underscores, but it seems somewhat strange when compared with random subset of other SOAP APIs, and we wouldn't really want to annoy consumers of API with our wrong convention.
In almost all standard SOAP API, I have seen, had CamelCaps. You may want to look standard SOAP API. i.e. google SOAP api
I think so Underscore may annoy users. You can follow either of them however more important is to follow any single standard naming conventions.
Other important thing to consider for naming a service is, naming should clearly establish a meaning and a context of the what service will do in a particular context.
i.e.
GetCustomerHistoryById = Get a single customers history by id
GetCustomersHistory = Get all customer's history
What language are you developing in (not that it matters)?
From my experience lower_with_underscores seems to be the preferred style for PHP development, but CamelCase seems to be more generally used.
Just a thought
For SOAP, you see either Pascal Casing or Camel Casing. The SOAP namespace is Pascal Cased (soap:Envelope anyone). I guess what you use depends on where you draw the line.
In general, I use Pascal Casing for Methods and Properties. These two elements embody the framework of the contract. Bearing this in mind, I would likely have SOAP elements that correspond to Methods and Properties Pascal Cased.
As for parameters and return values, I would have to think about breaking the Pascal casing rule and using camel casing there. Fortunatley, I am not building a SOAP API right now, so I have time to think about it.
I would not go with something outside of Pascal or Camel casing, however, as it is non standard. Not that I think people would say "I am not using YOUR API because it uses non-standard naming", but just as a matter of convention. But, then, people who buck convention often come up with the next new trend in development. ;-)