restexpress / restexpress Goto Github PK

Since Netty uses non-blocking I/O, using its worker threads to perform long-running activities, such as database and file I/O, etc. is not optimal. Instead, for long-running activities like this, utilize a thread pool to execute the service controller outside Netty's I/O worker thread(s).

Preliminary thoughts on design:

1. Netty pipeline simply creates RESTExpress Request.
2. Put Request on request queue.
3. Worker is freed to handle next request.
4. Service thread(s) read Request from request queue.
5. Handle request.
6. Place Response on response queue.
7. Netty pipeline monitors response queue and sends them back to client.

See also issue #25

DateAdapterJ works fine. However, JodaTime is very popular and seems to accomplish the same task. Speed-wise is it equivalent or better? If so, perhaps we can just roll it in.

Currently, all exceptions return text/plain and an HTTP status response code. This does not work well for some Javascript implementations. Marshal ALL responses into the requested mime type, including exceptions.

Utilize a plugin? to support caching best practices (e.g. RESTful Web Services Cookbook, Chapter 9).

Headers to set, according to the above reference:

• Cache-Control
• max-age
• Expires
• Pragma: no-cache
• Date

Support chunking by default. Allow configuration to turn it off via DSL/fluent interface.

When controller method returns empty string or string for JSON representation, content type is set to "text/plain" instead of "application/json"

Implement a testing console to support the testing of routes determined by introspection of /routes/metadata plugin.

See http://labs.omniti.com/labs/jsend for explanation on recommended response formatting. Make this optional, but easily implementable--like, by turning a switch.

Netty now has support for multi-part uploads. Offer a Route-DSL specifier to allow multi-part uploads for specific routes.

The format and query string influence the inbound and outbound serialization. Currently, if the URL refers to a non-existant resource, the error always gets marshaled to the default format. It should get marshaled to the requested format, if specified.

RestExpress is built to be the simplest thing that could possibly work--and only supports HTTP. Current thought is to utilize SSL off-loading and caching layers in front of RestExpress for maximum performance and scalability. However, HTTPS may make sense in some cases.

If no routes are defined for a given server, the startup should either display the number of routes defined or throw an exception. Otherwise, produce some indication of how many routes are defined within the RestExpress server.

When I create a rest api in the query parameter format, is the only way to get the query parameters is

request.getQueryStringMap();

or there exists another way which URLDecode the parameter values and return the string data?

Netty limits the number of headers that can be processed in the header decoder. Netty also limits the number of query-string parameters allowed in the QueryStringDecoder.

Ensure the RestExpress utilizes both in the pipeline to mitigate the known HashDOS possibility.

Correctly handle and process 100-continue requests.

Revamp/enhance DSL/fluent interface to be more elegant and pass things through from RestExpress to each Route to support the concept of 'inheritance' but allow each route to be tweaked individually.

Support gzip in request and response. Test to ensure HTTP spec is observed.

The URL pattern returned by the metadata service (e.g. '/console/routes') needs to include the parsed-out parameter names in the pattern to facilitate more easily creating a page that populates those values.

For example, if the URL pattern is /products/{orderId}.{format} the output should include the parameters, 'orderId' and 'format'.

Be able to assign routes to a given executor pool so extremely-long-running requests don't interfere with the lesser-long-running requests. Routes default to a 'default' pool.

Possible route DSL:
route.executorPool("pool.foo"); // for all methods
route.executorPool("pool.long", HttpMethod.POST, HttpMethod.PUT, HttpMethod.DELETE);
route.executorPool("pool.short", HttpMethod.GET);

Possible server DSL:
server.executorPool("pool.foo", 15); // pool name, thread count
server.executorPool(25); // 'default' pool, thread count

Offer support for FIQL (see http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00) for filtering on the query-string.

Netty does not yet support multi-part file uploads. Even when it does, RestExpress might need to be tweaked to support it. Supporting it early would be helpful.

Currently, all responses are passed in entirety. Support streaming of large files such as video, images, static files, etc.

I want to use Mysql as my db

http://activitystrea.ms/

Enable RestExpress to return/stream static files (e.g. HTML, Javascript, etc.).

Create a kickstart application via script or command line much like Rails. For example:

$> restexpress FancyApp

would create a new kickstart application in the FancyApp directory with all classes and strings appropriately renamed.

I'm writing some integration tests against RestExpress, and the shutdown time seems to be taking 20 seconds. I'm not sure what I should be setting to get the server to forcibly release everything for a test.

I've stepped into the code and as far in as I can go, it seems to be bouncing around inside ExecutorUtil.java (lines 84 -115) waiting for worker threads to be cleaned up.

Should I be setting something somewhere in my tests to speed the shutdown?

I'm using JDK 1.7

This is my server launch script

public class Serve {
private static RestExpress server;

public static void main(String[] args) throws Exception {
    go();
    server.awaitShutdown();
}

public static void go() {
    server = new RestExpress()
            .setName("commerce")
            .setDefaultFormat(Format.JSON)
            .putResponseProcessor(Format.JSON, ResponseProcessors.json())
            .putResponseProcessor(Format.WRAPPED_JSON,
                    ResponseProcessors.wrappedJson())
            .addMessageObserver(new SimpleConsoleLogMessageObserver());
    defineRoutes(server);
    server.bind(9050);
}

public static void defineRoutes(RestExpress server) {
    server.uri("/search", new Controller())
            .method(HttpMethod.POST, HttpMethod.GET)
            .flag(Flags.Cache.DONT_CACHE); // Expressly deny cache-ability.
}

public static void stop() {
    server.shutdown();
}
}

Utilize a config directory structure named after the environment with environment properties contained therein.

For example:
config/dev/environment.properties
config/testing/environment.properties
config/prod/environment.properties

Pass the runtime environment to the RestExpress main() method to use the desired configuration.

1. Create a sample application that can be used for benchmarking RestExpress functionality.
2. Publish benchmark statistics and charts.

Perhaps against other frameworks? For example: Tomcat/Jersey, Restlet

Two of the stub files generated by RestExpress contain licensing information. Is that your intent?

The two files are:

1. ResponseProcessors.java
2. Constants.java

Both have an Apache 2.0 license, meaning users will have to carry the StrategicGains copyright statement in the code they generate.

Hi,

I need to use a remote service which can be called asynchronously. This means that I can use the worker thread without blocking the thread, but I don't know how to do it within the controller. We only have access to the request and the response so I don't know how to use some kind of future to make the external service call.

I would appreciate your suggestions.

Regards,
Miguel

currently the routes support exactly those formats (serializations) specified globally. Some routes might support additional formats, or fewer at the route level.

Currently .xml and .json format types are supported. However, jsend-style responses are dictated by the service implementation. Implementing a .jsend format type would allow for the client to decide what style of response they wanted.

Support asynchronous handling of services by not blocking for controllers. In other words, initiate the controller action and return the thread to the pool, waiting for a response from the controller asynchronously--to boost performance.

/foo/bar.json would return JSON. /foo/bar.xml would return XML. However, /foo/bar.blah now returns JSON. Should return 404 as the resource is not found--unless 'blah' is added as a supported type in the route DSL.

Implement functionality at least as an example of how to implement conditional GET logic.

Hi,

We need to implement restful service accepting JSON string of approx 165 to 200 byte and submitting to RabbitMQ for further processing. In your post (http://toddfredrich.com/introducing-restexpress-instant-restful-services-in-java.html) you have mentioned that you have seen 15,000+ requests per second.

Can you please elaborate that does it mean that server was able to handle those many request per second and was able to reply. Can you share some more technical details like what would be required to achieve such performance?

I have tried executing Apache benchmark with your “kick start” example and was able to see performance around 1K.

I would appreciate your thoughts/suggestions.

regards,
Jaymin

Update RestExpress to use Jackson for both JSON and XML processing, reducing the number of external dependencies (e.g. GSON and XStream).

curl -i localhost:8081/routes/console.html

now returns a 400 Bad Request, presumably due to the enforcement of the .format specifier and not globally supporting HTML as a format.

This error occurs in branch v0.8.0

Create a plugin manager to update/manage plugins for your RESTExpress projects

Create a pom file to support Maven-style dependency management.

While the HTTP spec allows periods ('.') in the URL, RestExpress does not, due to the .{format} specifier at the end of the URL. This causes issues with some clients. Supporting the fully URL spec would be helpful.

Create a Plugins directory (or some-such), where if plugin jars are dropped in that directory, those plugins are automatically registered with the RESTExpress server on startup.

Create serializer(s) that respond to .html format and create a view from a returned model.

Whilst not technically a problem with the code, this project should have a group or forum to discuss how to get the most from it.

Unless I just haven't found it?

Provide a RestExpress Dynamic Test Console where:

1. get /_routes/_metadata provides a response that lists metadata about the routes available, their url, methods, etc.
2. get /_routes/_console returns a text/html response that, when loaded in a browser, provides an interface for testing the routes.

Some routes return something other than JSON or XML but are not simply text/plain. Support the setting of outbound mime type for each response.

Support Atom/RSS output from routes. Parsing/consumption can come later.

The FilterCallback.filterOn() method currently takes a String name and String value. Refactor it to accept a FilterComponent, to correspond with OrderCallback.orderBy() which takes an OrderComponent.

Implement content-type negotiation that will come into effect if a format specifier (e.g. ".json") is omitted. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 for details.