Im creating an API using Java and Spring. My question is, is there a standard way to organize the API routes into one file?
For example when creating an API using Express.JS there is one file, called the router, where all of the routes are declared and set up.
With Spring's annotation-based MVC framework it seems like the routes are scattered through various controllers. So if someone who didn't write the API needed to make changes to it they would be left searching through files to find the specific route.
Is there a standard practice or pattern that would create a central router? Im thinking about just creating a router class however I would then have to create instances of MANY classes in that router. It doesn't seem very clean.
XML configuration used to be the only way to do it, but if I remember correctly, the usual usage was to have one method per controller.
There's a fairly nice implementation of what you're looking for in the third-party springmvc-router project, which will let you configure your routes something like:
GET /user/? userController.listAll
GET /user/{<[0-9]+>id} userController.showUser
DELETE /user/{<[0-9]+>id} userController.deleteUser
POST /user/add/? userController.createUser
Related
What I'm trying to do is look directly at the incoming web request and manually select a controller to handle it. So far, I have created a custom implementation of IControllerFactory, but it seems that this runs after routing. Since the requests that are coming in don't match a route registered with MVC, it immediately goes to 404.
What I'm trying to figure out is how I can skip the routing portion straight to IControllerFactory step.
This sounds super odd, but I'm doing a proof of concept on creating routes at runtime. The idea is that, at runtime, I can download and load an assembly that has some controllers in it (i.e. a plugin) and then attempt register the route without restarting the service. I have most of it worked out I think, but I'm trying to figure out the routing part and it seemed easiest to simply grab the request and manually select the controller.
I've looked into implementing IRouter and then using app.UseRouter(myRouter) but I couldn't quite find what I was looking for.
Suggestions?
I'm creating a new application in Zend Framework 3 and i have a question about a design pattern
Without entering in much details this application will have several Services, as in, will be connecting to external APIs and even in multiple databases, the workflow is also very complex, a single will action can have multiple flows depending on several external information (wich user logged in, configs, etc).
I know about dependency injections and Zend Framework 3 Service Manager, however i am worried about instanciating sereval services when the flow will actually use only a few of them in certain cases, also we will have services depending on other services aswell, for this, i was thinking about using singletons.
Is singleton really a solution here? I was looking a way to user singletons in Zend Framework 3 and haven't figured out a easy way since i can't find a way to user the Service Manager inside a service, as I can't retrive the instance of the Service Manager outside of the Factory system.
What is an easy way to implement singletons in Zend Framework 3?
Why use singletons?
You don't need to worry about too many services in your service manager since they are started only when you get them from the service manager.
Also don't use the service manager inside another class except a factory. In ZF3 it's removed from the controllers for a reason. One of them is testability. If all services are inject with a factory, you can easily write tests. Also if you read your code next year, you can easily see what dependencies are needed inside a class.
If you find there are too many services being injected inside a class which are not always needed you can:
Use the ProxyManager. This lazy loads a service but doesn't start it until a method is called.
Split the service: Move some parts from a service into a new service. e.g. You don't need to place everything in an UserService. You can also have an UserRegisterService, UserEmailService, UserAuthService and UserNotificationsService.
In stead of ZF3, you can also think about zend-expressive. Without getting into too much detail, it is a lightweight middleware framework. You can use middleware to detect what is needed for a request and route to the required action to process the request. Something like this can probably also done in ZF3 but maybe someone else can explain how to do it there.
I'm building an Ember application with ember-cli and, as a persistence layer, an HTTP API using rails-api + Grape + ActiveModelSerializer. I am at a very basic stage but I want to setup my front-end and back-end in as much standard and clean way as possible before going on with developing further API and ember models.
I could not find a comprensive guide about serialization and deserialization made by the store but I read the documentation about DS.ActiveModelSerializer and DS.ActiveModelAdapter (which says the same things!) along with their parent classes.
What are the exact roles of adapter and serializer and how are they related?
Considering the tools I am using do I need to implement both of them?
Both Grape/ActiveModelSerializer and EmberData offer customization. As my back-end and front-end are for each other and not for anything else which side is it better to customize?
Hmmm...which side is better is subjective, so this is sort of my thought process:
Generally speaking, one would want an API that is able to "talk to anything" in case a device client is required or in case the API gets to be consumed by other parties in the future, so that would suggest that you'd config your Ember App to talk to your backend. But again, I think this is a subjective question/answer 'cause no one but you and your team can tell what's good for a given scenario you are or might be experiencing while the app gets created.
I think the guides explain the Adapter and Serializer role/usage and customization pretty decently these days.
As for implementing them, it may be necessary to create an adapter for your application to define a global namespace if you have one (if your controllers are behind another area like localhost:3000/api/products, then set namespace: 'api' otherwise this is not necessary), or similarly the host if you're using cors, and if you're doing with cli you might want to set the security policy in the environment to allow connections to other domains for cors and stuff like that. This can be done per model as well. But again, all of this is subjective as it depends on what you want/need to achieve.
I have read through the documentation many times over and search all over for the answer to this question but have come up short. Specifically I've looked at Defining the service and the Cornice API for a service and at Defining resource for resource.
I'm currently building a REST API that will have a similar structure to this:
GET /clients # Gets a list of clients
GET /clients/{id} # Gets a specific client
GET /clients/{id}/users # Gets a specific clients users
What would be the best way to go about this? Should I use a service or a resource or both? And, if both, how?
Resources are high-level convenience, services offer lower level control.
I am just learning cornice myself. Looking at the source code, a Resource creates Services internally, one for the item and one for the collection (if a collection path is specified). The resource also adds views to the services for each method defined with an http verb as the name or in the form collection_[verb].
So there is little difference except that resources are a neat, structured way to define services.
The resource decorator uses a url for the collection, as well as a url pattern for an object.
collection_path=/rest/users
path=/rest/users/{id}
The resource decorator is best used in view classes where you can use get/put/post/delete methods on the objects, as well as collection_get, collection_put, etc. on the collection. I have some examples here:
https://github.com/umeboshi2/trumpet/blob/master/trumpet/views/rest/users.py
Since I make heavy use of the resource decorator and view classes, I haven't found a need for the service function, but it allows you to create get,put,post decorators that wrap view callable functions.
If you are using backbone.js on the client side, the resource decorator and url examples work well with the Backbone collections and models.
I have two doubts
1)I am using sencha touch 2.1 for my application. And i want to create a common class for AJAX request because i am going to call from many controllers. Now my question is inside which directory(like model,store,controller) the common class for AJAX will come.And how i refer that class in app.js
2)I want to set some configs like common url,text,etc for my app. How can i achieve this.
Thanks in advance.
1) Ext.Ajax is a singleton class of Ext.data.Connection, so you can already use it throughout your application without creating many instances.
2) As stated in the Ext.Ajax documentation, you can simply set Ext.data.Connection configs on the Ext.Ajax instance.
Ext.Ajax.setUrl('defaultUrl.json');
Ext.Ajax.request({}); // will use the above URL
You can get a list of all the available configs by looking at the Ext.data.Connection class reference.