Share |

Home > Archive > Developers/reference > Overview > Architecture

ARCHITECTURE

SpicyNodes is a Web service created using the REST (Representational State Transfer) architectural style. The components that make up the structure of SpicyNodes are as follows:
  • Developer’s web site or page, in which the nodes and settings may be configured through a GUI or by directly editing the XML files. The nodemap XML file may also be generated programmatically.
  • Client web site, in which a nodemap is initiated and displayed. A user can traverse the node network by clicking on related nodes displayed on the page. The client web site also stores custom descriptive text and graphics referenced by the nodemap XML file.
  • SpicyNodes engine, which combines the node and setting information with the needed styles and fonts to create the nodemap requested by the client. Any custom client content referenced in the nodemap XML file is loaded on the fly.
  • XML configuration files for nodes and settings. The nodemap file stores node names and descriptions. It can also reference custom descriptive text or graphics stored on the client site. The settings file stores nodemap appearance parameters.
  • Styles and fonts library, which contains an inventory of available styles and fonts for use by the client. Only the components specified by the client are loaded at any one time.

Like other REST-based applications, SpicyNodes utilizes standardized, extensible Web technologies (XML, HTTP, URIs) and eliminates the need for cumbersome APIs and proprietary protocols. SpicyNodes’ use of HTTP puts it in complete alignment with the Web, while allowing it to leverage built-in HTTP features such as authentication, access control, and caching for enhanced performance.

The architecture of SpicyNodes embodies the basic principles of REST in the following ways:

  • Addressable and networked resources: Each node is modeled as a URI-addressable resource with the node hierarchy and relationships stored in XML format. Color, style, and animation parameters are also stored in XML format.
  • Uniform interface: The user interacts uniformly with each resource by clicking on a node and dispatching a HTTP GET request.
  • Representation of resources: Each HTTP response carries a nodemap representation of the underlying resource.
  • Statelessness: Authentication is carried out with each request and each request contains all the information needed to retrieve the desired nodemap.
  • State transfer through representation: Each representation of a node, i.e., the nodemap, carries within it links to other related states or node representations. Thus, the user can move from one node to another by clicking on a link provided within the current page.
  • Scalability: New nodes may be easily added anywhere in the hierarchy by modifying the nodemap XML file.

Share |