The Tasks Service with Collection+JSON

The Task Service implementation has the same functionality as the one that exists in the TPS web API. The only substantial difference is that I’ve stripped out support for all the other objects (Users and Notes). Most all the code is the same as what you’ve seen in the previous chapters and I won’t review that here. I will, however, show some snippets from the initial API server router (app.js) to highlight changes to make this a single-capability service.

Following is a snippet from the ms-tasks project’s app.js file—the root file of the Task Service:

var port = (process.env.PORT || 8182); 
var cjType = "application/vnd.collection+json"; 

var reRoot = new RegExp('^/$','i'); 
var reFile = new RegExp('^/files/.*','i');
var reTask = new RegExp('^/task/.*','i');

// request handler
function handler(req, res) {
  var segments, i, x, parts, rtn, flg, doc, url;

  // set local vars
  root = '//'+req.headers.host;
  contentType = contentType;
  flg = false;
  file = false;
  doc = null;

  // default to Cj 
  contentAccept = req.headers["accept"];
  if(!contentAccept || contentAccept.indexOf(cjType)!==-1) {
    contentType = contentType;
  }
  else {
    contentType = cjType;
  }
  ...
}

The highlights of this snippet are:

Set the listener port for this service. I used 8184 for my local running instances.

Set the media type for this service to be application/vnd.collection+json.

Set up the routing rules for root, task, and general file requests.

Force the incoming accept header to result in application/vnd.collection+json.

A more robust way to handle content negotiation might be to simply return "415 - Unsupported media type" if a client makes a call that does not resolve to application/vnd.collection+json, but it is common (and well within the HTTP specifications) for services to ignore incoming accept headers and just blurt out the only format they know. The client needs to account for that, too.

The other app.js snippet worth seeing here is the one that handles the routing of requests:

...
  // parse incoming request URL 
  parts = [];
  segments = req.url.split('/');
  for(i=0, x=segments.length; i<x; i++) {
    if(segments[i]!=='') {
      parts.push(segments[i]);
    }
  }

  // re-direct / to /task/ 
  try {
    if(flg===false && reRoot.test(req.url)) {
      handleResponse(req, res,
       {code:302, doc:"", headers:{'location':'//'+req.headers.host+"/task/"}});
    }
  }
  catch (ex) {}

  // task handler 
  try {
    if(flg===false && reTask.test(req.url)) {
      flg = true;
      doc = task(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // file handler 
  try {
    if(flg===false && reFile.test(req.url)) {
      flg = true;
      utils.file(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // final error 
  if(flg===false) {
    handleResponse(req, res, utils.errorResponse(req, res, 'Not Found', 404));
  }
...

And the key points are:

Parse the incoming URL into a collection of parts for everyone to deal with.

If the call is to the root, redirect the client to the /task/ URL.

Handle any /task/ requests.

Handle by /file/ requests.

Emit a 404 error for any other requests.

What is not shown here is the Task connector and component code as well as the Cj representor code. We’ve seen that already and you can check out the source code for details.

Now, with this service up and running, the response you get when you send a direct request to the /task/ URL looks like this:

{
  "collection": {
    "version": "1.0",
    "href": "//localhost:8182/task/",
    "title": "TPS - Tasks",
    "content": "<div>...</div>",
    "links": [
      {
        "href": "http://localhost:8182/task/",
        "rel": "self task collection","prompt": "Tasks"
      }
    ],
    "items": [
      {
        "rel": "item","href": "//localhost:8182/1l9fz7bhaho",
        "data": [
          {"name":"id","value":"1l9fz7bhaho","prompt":"ID","display":"true"},
          {"name":"title","value":"extensions","prompt":"Title",
            "display":"true"},
          {"name":"tags","value":"forms testing","prompt":"Tags",
            "display":"true"},
          {"name":"completeFlag","value":"true","prompt":"Complete Flag",
            "display":"true"},
          {"name":"assignedUser","value":"carol","prompt":"Asigned User",
            "display":"true"},
        ],
        "links": [
          {
            "prompt": "Assign User","rel": "assignUser edit-form",
            "href": "//localhost:8182/task/assign/1l9fz7bhaho"
          },
          {
            "prompt": "Mark Completed","rel": "markCompleted edit-form",
            "href": "/localhost:8182/task/completed/1l9fz7bhaho"
          },
          {
            "prompt": "Mark Active","rel": "markActive edit-form",
            "href": "//localhost:8182/task/active/1l9fz7bhaho"
          }
        ]
      }
      ...
    ],
    "queries": [...],
    "template": {
      "prompt": "Add Task","rel": "create-form //localhost:8182/rels/taskAdd",
      "data": [
        {"name": "title","value": "","prompt": "Title","required": true},
        {"name": "tags","value": "","prompt": "Tags"},
        {"name": "completeFlag","value": "false","prompt": "Complete"}
      ]
    }
  }
}

So, we have a Task Service up and running. Let’s move on to the User Service next.

The User Service with Siren

Just like the Task Service, the User Service I created is a single-capability microservice that allows consumers to manipulate User objects via the web API. This time, I rigged the User Service to only speak Siren. So all consumers will get Siren responses.

And the top app.js file looks like this:

var port         = (process.env.PORT || 8183); 
var sirenType    = "application/vnd.siren+json"; 

var csType       = '';
var csAccept     = '';

// routing rules
var reRoot = new RegExp('^/$','i');
var reFile = new RegExp('^/files/.*','i');
var reUser = new RegExp('^/user/.*','i');

// request handler
function handler(req, res) {
  var segments, i, x, parts, rtn, flg, doc, url;

  // set local vars
  root = '//'+req.headers.host;
  contentType = sirenType;
  flg = false;
  file = false;
  doc = null;

  // we handle siren here 
  contentAccept = req.headers["accept"];
  if(!contentAccept || contentAccept.indexOf(sirenType)!==-1) {
    contentType = contentType;
  }
  else {
    contentType = sirenType;
  }
  ...
}

Note the use of a new local port () of 8183, the setting of the default media type to application/vnd.siren+json (), and the forcing of the accept header to the siren media type (at ).

The other User Service snippet (shown next) is the routing code which includes:

Parsing the URL.

Redirecting root requests to /user/.

Handling User calls.

Handling any calls to the '/files/ URL space.

Emitting 404 - Not Found for everything else.

  // parse incoming request URL 
  parts = [];
  segments = req.url.split('/');
  for(i=0, x=segments.length; i<x; i++) {
    if(segments[i]!=='') {
      parts.push(segments[i]);
    }
  }

  // re-direct / to /user/ 
  try {
    if(flg===false && reRoot.test(req.url)) {
      handleResponse(req, res,
       {code:302, doc:"", headers:{'location':'//'+req.headers.host+"/user/"}});
    }
  }
  catch (ex) {}

  // user handler 
  try {
    if(flg===false && reUser.test(req.url)) {
      flg = true;
      doc = user(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // file handler 
  try {
    if(flg===false && reFile.test(req.url)) {
      flg = true;
      utils.file(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // final error 
  if(flg===false) {
    handleResponse(req, res, utils.errorResponse(req, res, 'Not Found', 404));
  }
}

As you would expect, the responses from the User Service look like this:

{
  "class": ["user"],
  "properties": {
    "content": "<div>...</div>"
  },
  "entities": [
    {
      "class": ["user"],
      "href": "//localhost:8183/user/alice",
      "rel": ["item"],
      "type": "application/vnd.siren+json",
      "id": "alice",
      "nick": "alice",
      "email": "[email protected]",
      "password": "a1!c#",
      "name": "Alice Teddington, Sr.",
      "dateCreated": "2016-01-18T02:12:55.747Z",
      "dateUpdated": "2016-02-07T04:43:44.500Z"
    }
    ...
  ],
  "actions": [
    {
      "name": "userFormAdd","title": "Add User",
      "href": "http://rwcbook11.herokuapp.com/user/",
      "type": "application/x-www-form-urlencoded",
      "method": "POST",
      "fields": [
        {"name": "nick","type": "text","value": "","title": "Nickname",
          "required": true, "pattern": "[a-zA-Z0-9]+"},
        {"name": "email","type": "email","value": "","title": "Email"},
        {"name": "name","type": "text","value": "","title": "Full Name",
          "required": true},
        {"name": "password","type": "text","value": "","title": "Password",
          "required": true,"pattern": "[a-zA-Z0-9!@#$%^&*-]+"
        }
      ]
    }
    ...
  ],
  "links": [
    {
      "rel": ["self","user","collection"],
      "href": "http://locahost:8183/user/",
      "class": ["user"],"title": "Users",
      "type": "application/vnd.siren+json"
    },
    {
      "rel": ["profile"],
      "href": "http://rwcbook17.herokuapp.com/user/", 
      "class": ["user"],"title": "Profile",
      "type": "application/vnd.siren+json"
    }
  ]
}

Note the appearance of the profile link in the response (). This is a reference to the POD extension we created in Chapter 6, Siren Clients to make it easier to pass domain object information to Siren responses.

Now we need one more base-level service—the Notes Service.

The Notes Service with HAL

I implemented the Notes Service as a standalone single-capability component that speaks HAL. Like the others, the only thing I needed to do to create the service is to strip down the app.js file to only respond to /note/ calls and only return HAL-formatted responses.

Here’s the top of the app.js file with the new port (8184 at ), default media type (), and accept processing (at ).

// shared vars
var port         = (process.env.PORT || 8184); 
var halType     = "application/vnd.hal+json"; 

var csType       = '';
var csAccept     = '';

// routing rules
var reRoot = new RegExp('^/$','i');
var reFile = new RegExp('^/files/.*','i');
var reNote = new RegExp('^/note/.*','i');

// request handler
function handler(req, res) {
  var segments, i, x, parts, rtn, flg, doc, url;

  // set local vars
  root = '//'+req.headers.host;
  contentType = halType;
  flg = false;
  file = false;
  doc = null;

  // it's a HAL world 
  contentAccept = req.headers["accept"];
  if(!contentAccept || contentAccept.indexOf(htmlType)!==-1) {
    contentType = contentAccept;
  }
  else {
    contentType = halType;
  }

The routing code also should look very familiar now:

  ...
  // parse incoming request URL
  parts = [];
  segments = req.url.split('/');
  for(i=0, x=segments.length; i<x; i++) {
    if(segments[i]!=='') {
      parts.push(segments[i]);
    }
  }

  // handle options call
  if(req.method==="OPTIONS") {
    sendResponse(req, res, "", 200);
    return;
  }

  // handle root call (route to /note/)
  try {
    if(flg===false && reRoot.test(req.url)) {
      handleResponse(req, res,
        {code:302, doc:"", headers:{'location':'//'+req.headers.host+"/note/"}}
      );
    }
  }
  catch (ex) {}

  try {
    if(flg===false && reNote.test(req.url)) {
      flg = true;
      doc = note(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // file handler
  try {
    if(flg===false && reFile.test(req.url)) {
      flg = true;
      utils.file(req, res, parts, handleResponse);
    }
  }
  catch(ex) {}

  // final error
  if(flg===false) {
    handleResponse(req, res, utils.errorResponse(req, res, 'Not Found', 404));
  }
}

And the Note Service responds in HAL, as expected (this is an abbreviated display):

{
  "_links": {
    "collection": {
      "href": "http://localhost:8184/note/",
      "title": "Notes","templated": false},
    "note": {"href" : "http://localhost:8184:/note-note"},
    "profile": {"href": "http://localhost:8184/note.pod"},
  },
  "content": "<div>...</div>",
  "related": {"tasklist": [ ... ]},
  "id": "aao9c8ascvk",
  "title": "Sample",
  "text": "this note was created using the Note microservice for the TPS API.",
  "assignedTask": "1l9fz7bhaho",
  "dateCreated": "2016-02-13T19:26:25.686Z",
  "dateUpdated": "2016-02-13T19:26:25.686Z"
}

Notice the profile link that appears in the response. This is a reference to the same POD extension that was added to the Siren representation (see “The POD Specification”) and the collection and note links that can be used to make HAL-FORMS calls (see “The HAL-FORMS Extension”). Now, this service’s HAL response is providing Object metadata (via POD), Action metadata (via HAL-FORMS), and the Addresses (via the native HAL _link array).

So, that’s all the base-level microservices. The real work is in the next section. That’s when we’ll modify the Home Service to serve up the TPS client that is able to talk in multiple languages.

The Home Service

The Home Service I created has two important jobs:

• Act as a gateway for all the other microservices (Tasks, Users, Notes).

• Serve up the standalone multiformat client that is capable of consuming the APIs of those microservices.

First, when dealing with loosely coupled microservices, it is hard for any one component to know the details about all the others. Instead, most microservice implementations rely on a proxy or gateway to resolve requests at runtime and make sure they end up at the right place.

I didn’t want to build a standalone API gateway and I didn’t want you to have to select and install one for this book. Instead I wrote a tiny bit of “proxy code” into the Home Service. And here’s how I did it.

First, I hardcoded some addresses for both a local version of the microservices and a remote running version of them:

// services
var addr = {};
addr.local = {};
addr.remote = {};
addr.selected = {};
addr.local.taskURL = "//localhost:8182/task/";
addr.local.userURL = "//localhost:8183/user/";
addr.local.noteURL = "//localhost:8184/note/";
addr.remote.taskURL = "//rwcbook16.herokuapp.com/task/";
addr.remote.userURL = "//rwcbook17.herokuapp.com/user/";
addr.remote.noteURL = "//rwcbook18.herokuapp.com/note/";

Next, near the top of the app.js for the Home Service, I added a bit of code that inspects the incoming request’s host header to see where that request is heading and use that to select a set of addresses:

// fix up redirects
if(root.indexOf("localhost")!==-1) {
  addr.selected = addr.local;
}
else {
  addr.selected = addr.remote;
}

Finally, whenever a consumer of the Home Service makes a call to one of the related services, I redirect that call to the proper standalone service component:

// task handler (send to external service)
try {
  if(flg===false && reTask.test(req.url)) {
    handleResponse(req, res, {code:302, doc:"",
      headers:{'location':addr.selected.taskURL}});
  }
}
catch(ex) {}

// user handler (send to external service)
try {
  if(flg===false && reUser.test(req.url)) {
    handleResponse(req, res, {code:302, doc:"",
      headers:{'location':addr.selected.userURL}});
  }
}
catch(ex) {}

// note handler (send to external service)
try {
  if(flg===false && reNote.test(req.url)) {
    flg = true;
    handleResponse(req, res, {code:302, doc:"",
      headers:{'location':addr.selected.noteURL}});
  }
}
catch(ex) {}

Now the client hosted by the Home service doesn’t need to know anything about where these other services are located. It just makes a call back to the Home service (e.g., /task/). Upon receiving the client request, the Home service selects the proper URL and passes that URL back to the client (via a 302 Redirect request). The client then uses this new URL to make a direct call to the running microservice.

In this way, the Home service does not handle the microservice requests, just the ones specific to the Home service. The remainder of the Home service is dedicated to serving up the HTML SPA container and associated JavaScript files for the client. We’ll look at that next.

The Multiformat Client SPA Container

The first thing to review is the HTML SPA container for our multiformat client. It looks similar to previous containers except for one thing. This container has bits of markup from the three previous containers all in one.

I’ll review the SPA container in a few key snippets. The first one is the top of the HTML <body> section. It contains a fixed menu area () that holds a set of relative URLs—one for each service. There is also a “shared layout” area () that holds the title, content, and error elements. The fixed elements are new for our clients, but the other sections should look familar.

<!DOCTYPE html>
<html>
  <body>
    <!-- fixed menu -->
    <div id="menu"> 
      <div class="ui blue fixed top menu">
        <a href="/home/" rel="home" class="item" title="Home">Home</a>
        <a href="/task/" rel="task" class="item ext" title="Tasks">Tasks</a>
        <a href="/user/" rel="user" class="item ext" title="Users">Users</a>
        <a href="/note/" rel="note" class="item ext" title="Notes">Notes</a>
      </div>

      <!-- shared layout --> 
      <h1 id="title" class="ui page header"></h1>
      <div id="content" style="margin: 1em"></div>
      <div id="error"></div>
    </div>
    ...

The next three markup blocks in the HTML container match up to the three media type formats this client understands. For example, here is the markup for handling Collection+JSON responses:

<!-- cj layout -->
<div id="cj" style="display:none;">
  <div id="c-links" style="display:none;"></div> 
  <div style="margin: 5em 1em">
    <div class="ui mobile reversed two column stackable grid">
      <div class="column">
        <div id="c-items" class="ui segments"></div> 
      </div>
      <div class="column">
        <div id="c-edit" class="ui green segment"></div> 
        <div id="c-template" class="ui green segment"></div> 
        <div id="queries-wrapper">
          <h1 class="ui dividing header">
            Queries
          </h1>
          <div id="c-queries"></div> 
        </div>
      </div>
    </div>
  </div>
</div>

Note the callouts show Cj-specific elements for links (), items (), an edit block (), the template (), and queries ().

The next markup block in the client is for rendering Siren responses where the callouts identify the siren links (), properties (), entities (), and actions ():

<!-- siren layout -->
<div id="siren" style="display:none;">
  <div id="s-links"></div> 
  <div style="margin: 5em 1em">
    <div class="ui mobile reversed two column stackable grid">
      <div class="column">
        <div id="s-properties" class="ui segment"></div> 
        <div id="s-entities" class="ui segments"></div> 
      </div>
      <div class="column">
        <div id="s-actions"></div> 
      </div>
    </div>
  </div>
</div>

Then there is the HAL section of markup which holds the links, embedded, and properties (, and , respectively). There is also an element to hold all the input forms () for HAL interactions:

<!-- hal layout -->
<div id="hal" style="display:none;">
  <div style="margin: 5em 1em">
    <div id="h-links" style="margin-bottom: 1em"></div> 
    <div class="ui mobile reversed two column stackable grid">
      <div class="column">
        <div id="h-embedded" class="ui segments"></div> 
        <div id="h-properties"></div> 
      </div>
      <div class="column">
        <div id="h-form"></div> 
      </div>
    </div>
  </div>
</div>

Finally, at the bottom of the HTML page is a series of references to JavaScript files ()—one for each format (cj-lib.js, siren-lib.js, and hal-lib.js) along with the local client files (, dom-help.js and home.js). At , you can see the home client firing up and waiting for the next human interaction:

  <script src="cj-lib.js">//na </script> 
  <script src="siren-lib.js">//na </script>
  <script src="hal-lib.js"?>//na </script>
  <script src="dom-help.js">//na </script>
  <script src="home.js">//na </script> 
  <script>
    window.onload = function() { 
      var pg = home();
      pg.init();
    }
  </script>

The Format-Switching Client UI

As you might be able to guess from the way the HTML looks for the client, this app is designed to handle three different media type responses: HAL, Siren, and Cj. The way this works is that libraries for each of them are loaded at runtime and then, as each request comes in, it is routed to the proper library and rendered in the appropriate HTML block. That functionality is contained in the home.js script.

The home.js script is not very big, and there are two parts worth reviewing here. First, at the start of the home.js script, all the other format libraries are initialized and the static page is filled in.

Here’s what that code looks like:

function home() {

  var d = domHelp();
  var cj = cjLib(); 
  var siren = sirenLib();
  var hal = halLib();

  var global = {};
  global.accept = "application/vnd.hal+json,"  
    + "application/vnd.siren+json,"
    + "application/vnd.collection+json";

  // init library and start
  function init() {
    cj.init(this.req, this.rsp, "TPS - Tasks"); 
    siren.init(this.req, this.rsp, "TPS - Users");
    hal.init(this.req, this.rsp, "TPS - Notes");

    hideAll();
    setTitle();
    setHome();
    setLinks();
    setContent();
  }

In the preceding snippet you see where each library is loaded () and then intitialized (at ). Note that pointers to this module’s Ajax object (this.req and this.rsp) are passed to each format library. That makes sure all requests originate from this module where they can be further inspected and then properly routed. You can also see (at ) that the client’s HTTP ACCEPT variable is initialized to include all three of the formats this client understands when talking to services.

When up and running, the client code renders this menu and a bit of static content, then waits for user clicks (see Figure 9-1).

Figure 9-1. Rendering the home screen in the multiclient

Another important element in this snippet is at . This line of code sets the default accept header for our multiformat client by loading it with all three formats this client understands. Now, each initial request to any of the services will have the following value for the accept header:

Accept: application/vnd.hal+json, application/vnd.siren+json,
  application/vnd.collection+json

This is the HTTP way for a client to tell a server:

“Hey service, I understand these three formats. Please send your responses as either a HAL, Siren, or Cj message. kthxbye.”

It is up to the server to read and honor this request.

The other part of this default request is handling the response and routing it to the right library. In the home.js client code, the routing between libraries happens in the HTTP request handler. There, the library inspects the content-type header and routes the incoming response accordingly:

function rsp(ajax) {
  var ctype

  if(ajax.readyState===4) {
    hideAll();
    try {
      ctype = ajax.getResponseHeader("content-type").toLowerCase();
      switch(ctype) {
        case "application/vnd.collection+json":
          cj.parse(JSON.parse(ajax.responseText));
          break;
        case "application/vnd.siren+json":
          siren.parse(JSON.parse(ajax.responseText));
          break;
        case "application/vnd.hal+json":
          hal.parse(JSON.parse(ajax.responseText));
          break;
        default:
          dump(ajax.responseText);
          break;
      }
    }
    catch(ex) {
      alert(ex);
    }
  }
}

The code just shown looks very similar to the representor.js code we’ve seen in the server-side implementations used throughout the book (see “Implementing the Message Translator Pattern”). This client code is actually the mirror to that server code. That’s because this code is an implementation of a client-side representor. It takes the public representation (in HAL, Siren, or Cj) and converts that into the client’s base object graph, which is, for human-centric web browsers, the HTML DOM. The important difference is that the server-side representor uses the client’s accept header to route the internal object graph to the proper representor. And the client-side representor (seen previously) uses the server’s content-type header to route the external representation to the proper library to convert that message into a local HTML DOM for display.

Once the routing is decided, the entire response is passed to that library’s parsing routine to handle all the translating and rendering. So, let’s take a quick look at the media-type libraries for this client.

The Cj Render Library

In the following Collection+JSON render library (cj-lib.js) snippet, you can see the init() and parse() routines. At the init routine accepts the pointers to the shared ajax handlers. Once the rsp handler in home.js receives the server response and routes it back here (via the parse method), the incoming Cj message is stored () and the response is rendered () just as in the dedicated Cj client. After all the rendering is done, the <div id="cj>…</div> block is revealed () to wait for human interaction. It’s the classic Request, Parse, Wait (RPW) interaction pattern from Chapter 5 in action:

// init library and start
function init(req,rsp) { 
  global.req = req;
  global.rsp = rsp;
}

// primary loop
function parse(collection) {
  var elm;

  // store response
  global.cj = collection; 

  //render 
  dump();
  title();
  content();
  items();
  queries();
  template();
  error();
  cjClearEdit();

  // show
  elm = domHelp.find("cj"); 
  if(elm) {
    elm.style.display="block";
  }
}

Figure 9-2 shows what the actual HTML UI looks like when handling Cj responses from the Task Service.

Figure 9-2. Rendering Cj responses in the multiclient

The Siren render library

The Siren parse routine looks similar (including the “reveal” code at ). You’ll notice the title is passed in from the home.js routine. This is an optional item that covers the lack of a built-in title element in Siren. When using differing response formats in the same UI, there will naturally be some variances in the UI details, so adding these optional elements helps:

// init library and start
function init(req, rsp, title) {
  global.req = req;
  global.rsp = rsp;
  global.title = title||"Siren Client";
}

// primary loop
function parse(sirenMsg) {
  var elm;

  global.sirenMsg = sirenMsg;

  sirenClear();
  title();
  getContent();
  dump();
  links();
  entities();
  properties();
  actions();

  elm = domHelp.find("siren"); 
  if(elm) {
    elm.style.display="block";
  }
}

Figure 9-3 shows the same client rendering Siren responses from the User Service.

Figure 9-3. Rendering Siren responses in the multiclient

The HAL render library

And finally, the HAL parse routine (see the following code). By now, it should all seem rather straightforward. The pattern is simple: initialize the library with request and response pointers; when a request is routed into the library, render it as you usually do and then reveal the results for the human to deal with.

Here’s what the HAL initial code looks like:

// HAL init library and start
function init(req, rsp, title) {
  global.title = title||"HAL Client";
  global.req = req;
  global.rsp = rsp;
}

// primary loop
function parse(hal) {

  global.hal = hal;

  halClear();
  title();
  setContext();
  if(g.context!=="") {
    selectLinks("list", "h-links");
    content();
    embedded();
    properties();
  }
  else {
    alert("Unknown Context, can't continue");
  }
  dump();

  elm = domHelp.find("hal");
  if(elm) {
    elm.style.display="block";
  }
}

Figure 9-4 shows the rendering of HAL responses from the Note Service.

Again, the exact details of the UI vary depending on which response format is returned. This is natural. Just as we get varying UI displays when moving from one website to another with our default client (the web browser), we’ll likely experience the same varying UI experience when we move from one microservice to another while using our multilingual client.

An Experiment for the Reader

The microservices I implemented are actually able to deliver their functionality in more than one representation format. For example, the Task Service can speak HAL and Siren just as well as Cj. What do you think would happen to the multiformat client if you simply change the response formats of the microservices at runtime? If the client and microservers are coded properly, the apps would function just fine (although there’d be minor UI experience differences).

Figure 9-4. Rendering HAL responses in the multiclient

Let’s wrap this up with a short summary of what we learned in this chapter.