RESTx is not an application framework

RESTx is not an application framework

What differentiates RESTx from some of the other web application frameworks? For example, how is RESTx different from Ruby on Rails, Django, or even dedicated REST application frameworks such as RESTEasy or Restfulie? The answer is simple: RESTx is NOT an application framework at all. Instead, it's a platform to rapidly create RESTful web services and resources.

The traditional frameworks

When you use a traditional application framework it is up to you, the developer, to express everything in code or configuration files. Each framework is a bit different of course and offers a few nuances in features and approach. But for the most part, the following holds true:

  • You need to explicitly set up URI path to code routing, usually one path for each function.
  • In some frameworks, you also need to explicitly specify the HTTP methods and how they are mapped to functions for any given path, making it more tricky to work with "method-challenged" clients.
  • If you wish to reuse components, you need to explicitly deal with this in your code.
  • All configurations need to be provided ahead of time.
  • Most frameworks lock you into a single language, meaning you cannot easily switch to a programming language that is best suited for a particular 'handler' method.
  • Integrating results of one web service with data from another is typically not supported in any particular way and needs to be implemented manually.
  • Requirements for any new functionality, new resources or web services need to be addressed by the developers. Such an application is not like a wiki where users could create their own content: It's all in carefully crafted code and configuration.
  • Any exposed RESTful API or web services usually need to be documented separately, possibly maintained in an external repository, and so on. Clients either need to know how to use the services, or – if the RESTful principle of discoverability is to be supported – it needs to be implemented manually.

Admittedly, with the required explicit control over all details of your application, these frameworks give you a lot of power and – aside from the single-language lock-in and the need to do it all yourself – flexibility. Even though this usually means a lot of work for the developer, there are definitely lots of good use cases where traditional web application frameworks are exactly what you need.

The RESTx difference: Dynamic, simple, focused on resources

RESTx, on the other hand, does not concern itself with being an application framework. It gives you a whole lot of freedom and support in some areas, and takes away some requirements for explicit setup and control in others, in order to streamline your task and make it much simpler for you as the developer, as well as your users. Note: 'Users' here refers to end users in your organization, as well as client application developers, business partners, customers, etc.

Here are RESTx's key differences:

  • Built-in support for reusable component code: In RESTx, code is organized into distinct components, which normally don't interact with each other. Components are specialized pieces code, providing any functionality: Database access, processing/filtering of data, accessing particular cloud services (such as Salesforce), interacting with a custom API or legacy application, etc. These components are packaged in a re-usable manner and can be shared and exchanged with others.
  • On-the-fly creation of new resources: Parameter sets for components are sent to the server (programmatically or by filling out a small form), stored and made accessible via a simple ‘resource URI’, hiding any parameters. When the URI is accessed, the stored parameters are retrieved and components are invoked with them. Example “/resource/Top10Customer” is the URI of the resource, while accessing it invokes a database access component, with the necessary credentials and query string.
  • User-created resources: Organizations can react and move more quickly to changing requirements, since resources can be created on the fly by users or other groups within IT, simply and in a restricted but flexible environment. To address security concerns, RESTx offers means for IT or server administrators to restrict the parameters that users can modify when creating new resources.
  • RESTx resources are safer: The RESTx server handles the storage of component parameter sets and makes it possible to create resources without requiring a server restart. Consequently, creating new resources with RESTx is safer than with other frameworks: No global settings or code is modified, neither deliberately or accidentally.
  • Auto-generated RESTful, discoverable, crawlable API: RESTx examines component code and created resources. From that information it automatically creates a discoverable, human and machine readable RESTful API. No external repository of services, or manually implementing discoverability features are required.
  • Automatic handling of different content types: Depending on the client's HTTP request, the content type of input or output is automatically processed and adjusted by RESTx. Therefore, the same resources can be ‘seen’ in different ways, depending on the client’s needs. RESTx is easily extensible with handlers for new content types. Accepted input/output content types are reflected in the automatically created API.
  • Write components in the language that's right for you: From the start, RESTx has been designed to give developers a choice of programming languages. Currently, Java and Python are supported for the development of components, but more languages will be added soon.
  • Built-in support for integration: A common pattern for RESTx is to build resources around basic data sources and then provide data integration code as another special component. RESTx supports this pattern by allowing very straight forward access to specified resources from within component code.
  • Simplicity everywhere you look: RESTx does not require a long learning curve or huge organizational commitment or training. Simplicity was a major design goal from the very start. Getting started takes just minutes, it works out of the box with no configuration to edit, new components are created with a single command, APIs are small and easy, controlling the server is also done with just a single command.

Conclusion

By now you can see that RESTx is not an ordinary application framework. I wouldn't use it to write a shopping cart application, for example. On the other hand, if I would have to rapidly create access to legacy data, custom APIs or cloud services, with many variations on each of them, if I would like to quickly reuse components that have been provided by others, if I want to allow my power users and knowledge workers to create their own resources and web services on the fly, if I don't want to deal with having to document an API or maintain a repository of resources... well, then I would chose RESTx, because it is – we believe – the fastest and simplest way to create RESTful web services and resources.

What can you do next?