External REST Client Design in Node+Express+Angular

168 views
Skip to first unread message

dmank

unread,
Oct 7, 2014, 9:44:37 AM10/7/14
to nod...@googlegroups.com
Hey all,

I'd appreciate some input on a design decision that I'm trying to make.  I have a product that has a fairly robust REST API, with around 100 endpoints and options.  My hope is to setup a Node/Express/Angular stack with modules and libraries on each level to query that REST API, abstracting out the mechanics and specifics of the calls for other developers.  The goal is to have as little code as possible (both for myself and the developers) and keep the configuration fairly basic.

Let me setup an example, lets call the product that hosts REST services "DocManager" and it has hundreds of endpoints - three of which are "List Files", "Get File Details" and "Update File".  I'm struggling with the following options:
  • Option #1: Develop a "docmanager-rest-client" nodejs module responsible for wrapping each DocManager REST call (List Files, Get File Details, Update File), rely on the developer to build the routes and controllers to consume the functions.  No work in Angular.
  • Option #2: Develop a "docmanager-rest-proxy" using http-proxy to proxy/pipe REST requests from DocManager directly to Angular through nodejs.  All abstraction is done in Angular.
Are these community-acceptable approaches?  Are there any approaches that I'm missing here?  (Authentication is taken care of in either case through custom security)

Floby

unread,
Oct 8, 2014, 6:16:04 AM10/8/14
to nod...@googlegroups.com
I would go with option #2
This keeps your node.js lean. If you ever need an API endpoint that is too specific to your angular app to be in the main application, you can modify your proxy to do some funny stuff. Otherwise keep it a simple proxy to your original endpoint.

Ken

unread,
Oct 8, 2014, 3:04:55 PM10/8/14
to nod...@googlegroups.com
This is more about REST and Angular's way of working with services than anything node specific.  If your service is set up using the canonical REST "resource" pattern then Angular can grok it natively without the need for an explicit client module (nor the need for a proxy assuming your DocManager server is internet accessible and you have CORS configured properly.  For example "List Files" should be

  GET /files/

"Get File Details" should be

   GET /files/some-file

"Update File" should be

   POST /files/some-file

If you follow that pattern then Angular integration is just a one liner (this syntax may be a bit out of date, copied from some old code)

  angular.module('myModlule', ['ngResource']).factory('File', function($resource) {
      return $resource('http://myserver/files');
   });

If you're not already following that pattern on DocManager then using option 2 to map the existing DocManager API into a resource compliant one may make sense.  If you are following that pattern and just want to avoid CORS issues I'd suggest handling the proxy with something like nginx rather than writing any code to do it.

Floby

unread,
Oct 10, 2014, 4:43:44 AM10/10/14
to nod...@googlegroups.com
Update File should be

PUT /file/some--file


On Tuesday, 7 October 2014 15:44:37 UTC+2, dmank wrote:

dmank

unread,
Oct 10, 2014, 12:59:39 PM10/10/14
to nod...@googlegroups.com
All,

Thanks Floby and Ken for the input!  The REST API that I am wrapping is indeed not so close to the conventional resource pattern, sometimes it's on target and sometimes not.  Good points!

Miroslav Bajtoš

unread,
Oct 14, 2014, 3:57:00 AM10/14/14
to nod...@googlegroups.com
On Tuesday, October 7, 2014 3:44:37 PM UTC+2, dmank wrote:
Hey all,

I'd appreciate some input on a design decision that I'm trying to make.  I have a product that has a fairly robust REST API, with around 100 endpoints and options.  My hope is to setup a Node/Express/Angular stack with modules and libraries on each level to query that REST API, abstracting out the mechanics and specifics of the calls for other developers.  The goal is to have as little code as possible (both for myself and the developers) and keep the configuration fairly basic.

Let me setup an example, lets call the product that hosts REST services "DocManager" and it has hundreds of endpoints - three of which are "List Files", "Get File Details" and "Update File".  I'm struggling with the following options:
  • Option #1: Develop a "docmanager-rest-client" nodejs module responsible for wrapping each DocManager REST call (List Files, Get File Details, Update File), rely on the developer to build the routes and controllers to consume the functions.  No work in Angular.
  • Option #2: Develop a "docmanager-rest-proxy" using http-proxy to proxy/pipe REST requests from DocManager directly to Angular through nodejs.  All abstraction is done in Angular.

You may want to take a look at LoopBack, our API framework built on top of express:


It will allow you to mix both options:
 - On the server, you can declaratively map DocManager REST interface onto an object-based REST API to be consumed by your front-end.
 - Where appropriate, you can add your custom function to extend the models provided by DocManager.
 - On the client, you can generate ngResource definitions for your server api by running a single command or as part of your Grunt/Gulp build.
 - Where appropriate, you can implement extra logic that does not belong to the server.

Miroslav
Reply all
Reply to author
Forward
0 new messages