Extensibility

The Read Write Serve HTTP/2 server has an extensible architecture allowing you to develop chainable JavaScript plugins that work within the request/response cycle.

The modular architecture and plugin design of Read Write Serve HTTP/2 Server is all about extensibility. Making it happen with JavaScript is its raison d'être.

If you're evaluating RWSERVE for your next JavaScript project, here are a few things to help you understand what's possible.

HTTP Methods

Plugins can be directed to handle any combination of HTTP methods. The most typical ones being:

• Handling GET requests for database retrievals (multi-records listings and single-record pages).
• Handling POST requests for typical form submissions, file uploads, and asynchronous Fetch.
• Handling PUT requests when creating a database record through a REST API.
• Handling PATCH requests when updating a database record through a REST API.
• Handling DELETE requests when deleting a database record through a REST API.

Learn more about HTTP methods.

Plugin Tasks

Here are some typical tasks carried out by plugins.

• Honoring request values provided in query-string variables through the work order's parameterMap.
• Accessing x-www-form-urlencoded values via the work order's formDataMap.
• Accessing multipart/form-data to allow users to upload multiple files.
• Accessing individual cookie values through the work order's cookieMap.

Check out this plugin catalog to learn more about plugin tasks.

Work Order Functions

Here are some of the more important work-order functions used by plugins to process the request/response cycle:

• Implementing the optional startup method for initialization.
• Accessing plugin-specific variables declared in the configuration file.
• Adding a standard response header using addStdHeader.
• Setting an empty response body with setEmptyPayload.
• Setting the response status code with setStatusCode.
• Implementing the optional shutdown method to save state.

Learn more about request/response work orders.

Processing Patterns

Here are some typical processing patterns that plugins follow for integrating their work within the request/response cycle.

• Following the chainable processing pattern by omitting any calls to setStatusCode.
• Following the response-body processing pattern by calling setOutgoingPayload.
• Following the empty-body processing pattern by calling setEmptyPayload.
• Following the static file processing pattern when a resource request matches a file in the public document path.
• Following the terminal processing pattern by setting the status code to a value in the 400 to 416 range.
• Conditionally following the chainable processing pattern or the terminal processing pattern.

Learn more about plugin processing patterns.