#REST API

In our last lesson, we implemented a linkage to our WidgetAccessory class, and debugged some errors we encountered along the way.  We now have our data being returned by REST, but what if we want to update or add new data to our application?  

or "Things are going to break"

We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget.  However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application. 

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.

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?

We finished our last lesson with our Widgets Direct page iterating over a list of widgets, displaying an ID and a Name value.  While we have been able to achieve this with only a small amount of coding, the page itself is not the most visually appealing place to be.  The AngularJS framework is providing a powerful Model-View-Controller framework for our structure and logic, but it does not implement anything that will provide a nice UI experience.

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: 

In this article I'll cover testing and debugging Caché web applications (mainly REST) with external tools. Second part covers Caché tools.

You wrote server-side code and want to test it from a client or already have a web application and it doesn't work. Here comes debugging. In this article I'll go from the easiest to use tools (browser) to the most comprehensive (packet analyzer), but first let's talk a little about most common errors and how they can be resolved.

We are using an F5 load balancer to route public traffic to our IS server. My goal is to block public access to the Management Portal, and only allow what we want to expose, such as REST/SOAP services. At the F5, they can block URL wildcards or specific ports, so those are our options.

Since the URLs for the web services are in the same path ([host]/csp/healthshare/[namespace]/*), I can't see any URL wildcards happening. That leads me to ports; is there a way to put services on a specific port for all services, and everything else stay on a standard web port?

Maybe someone has a logger for  incoming CSP requests and willing to share? Debugging  high traffic HTTPS application and wireshark just doesn't cut it sometimes. So I thought I'd ask here.  I'm especially interested in getting raw stream of incoming request.

Hi

I tried to access one server to another server in Cache Rest Service, I tried 

Parameter HandleCorsRequest = 1;

and

<Route Url="/data/:first/:second" Method="GET" Call="GetData" Cors="true"/>

But not working,

Can anyone tell me the solution??

Thanks in advance!!

Let's say I need to process these urls in one REST method:

http://host:port/REST/arg1/arg2/arg3
http://host:port/REST/arg1/arg2/
http://host:port/REST/arg1/arg2
http://host:port/REST/arg
http://host:port/REST/

Currently I need to define URL Map like this (assuming /REST web app):

This question is about calling AWS REST APIs. Based on:

http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html

AWS requires REST clients to call their APIs using Signature Version 4 which in case you don't know what I am talking about is a pain in the neck.  Here comes the question:

Has anybody, by any chance implemented the v4 signing alg. in COS? If yes, would she or he have the kind heart to share?

Thanks,

Chris

I am relatively new to ensemble, but I am trying to build a REST operation using the enslib.Rest.Operation but I can't seem to get it to work at all. I am completely at loss here because the errors I am receiving are very unclear. I have tried a few different variants using PostURL and SendFormDataArray but I got errors on all variants. Suggestions are welcome.

I created a simple CRUD operation using Rest Services in Cache.