The idea of this post is to introduce Frontier: An abstraction layer that allows Rapid REST development.



Have you ever found yourself dealing with repetitive tasks like mounting objects, serializing them and eventually handling multiple errors for multiple cases? Frontier can boost your development by making you focus on what really matters: your application.

Frontier is made to stop you from WRITE'ing by instead forcing your methods to return values.
It's designed to make you code clean, and you'll see the why pretty soon.

This is the Part 1, where you'll learn he basics about how to work with Frontier. That means at the end of this part you should be capable of

creating GET requests without difficulties. Since this also serves as a way to introduce the framework, I'll be calling this part: Core concepts.

4 8
0 1.5K
· May 22, 2017 1m read
WebSockets v REST?

Most frameworks support either REST or WebSockets, and don't make it easy to switch between the two, and/or support both styles of application at the same time. WebSockets offer many advantages over REST, eg:

- most benchmarks show WebSocket messaging to be significantly faster than over HTTP

1 1
0 433

In our last lesson, we added some formatting and validation to our Edit Widget form. So, now we are ready to add the ability to add new Widgets to our application. However, the great Widget Wars have come to an abrupt end, as Widget Direct has purchased its biggest competitor, WorldWideWidgets. In order to maintain some continuity, we need to display their catalog on our new application.

2 0
0 703

Something that shot up the popularity stakes last week was this article on a very interesting initiative: RealWorld:


I decided it would be a good idea to use this as a way of creating an exemplar implementation of a RESTful back-end using QEWD against their published API (https://github.com/gothinkster/realworld/tree/master/api)

The results are here:

4 14
0 1.2K

or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"

Yes, that was the plan. This is a pretty important topic, so it get's its own Article

Up until now, we've display widget JSON that has been created by a basic loop. Clearly this isn't of much value. Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.

2 4
0 1.4K

At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards. Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list. What can we do to help?

3 0
0 1.2K
· Apr 18, 2017 1m read
Having your Node.js Cake and Eating It Too

I've mentioned the QEWD project in this group before: it's a Node.js-based platform for web, Native and REST applications which tightly integrates with Cache. It uses a somewhat different philosophy to the use of Node.js than the norm, and I've now published an article that explains this approach and the unique benefits that arise as a result.

It turns out that, integrated via QEWD, Cache is an ideal bed-fellow for Node.js. QEWD makes the integration of Cache and Node.js exceptionally fast, simple and intuitive to use, but also extremely powerful.

Read the article here:

4 4
0 497

or "So you just got yelled at by your boss, for sending him an unformatted Hello World webpage"

Our previous lesson ended with us serving a Message value obtained from a Caché REST service to the client, using Angular as a runtime. While there is a lot of moving parts involved in this process, the page is not especially exciting at the moment. Before we can start adding new features, we should take a step back and review our tools.

11 1
1 2.4K
· Oct 7, 2016 4m read
Forwarding Requests in a REST Service

One useful feature of our REST framework is the ability for a dispatch class to identify request prefixes and forward them to another dispatch class. This approach of modularizing your URL map will improve code readability, enable you to easily maintain separate versions of an interface, and provide a means to protect API calls that only certain users will be allowed to access.

7 1
0 3.5K
· Oct 6, 2016 4m read
RESTful Exception Handling

A beginner’s guide to Exception Handling in RESTful web services. The article gives an example how the various error conditions during processing a service request can be handled.

We expect our client – server communication working in a flawless operational condition, running error free software. But we are prepared to handle exceptions. Are we? So far in the examples of the previous sessions were not. We did not care about exceptions. The result? In any error incident it took ages to figure out what the problem is and more importantly how to fix it.

3 1
0 1.6K
· Oct 5, 2016 13m read
RESTful way of data transfer

This article gives a brief introduction how a RESTful service consumer and a RESTful service provider exchange data. It is a beginner’s guide. Data is transferred from a consumer to a provider as parameters of the service. Parameters are part of a service request. The result of the service action a response is returned from a provider to a consumer. Both the service request and response are standard HTTP messages. Since HTTP is a flexible standard regarding to the message contents, RESTful services also enjoy the versatility of data transfer methods.

3 0
0 4.3K

RESTful API Call From Cache to Particle.io Electron

Tom Fitzgibbon | Multidata | 212-967-6700 x537 | tom@mul.com

Summary: Simple Blink Tutorial for Particle.io Electron Device from Cache

Electron device is a tiny ARM processor ($40-$60) that connects to Particle’s world wide leased 2G/3G network (about $3/mo) and runs off an included LiPo battery. Using Cache’s %Net.HttpRequest you can send/receive data, control hardware and read sensors.

Step by Step (about 1 hour)

1) Get the Electron from store.particle.io.

2 0
0 1.2K