Building Killer RESTful APIs with NodeJs

This deck and code are on GitHub:
https://github.com/srdjan/resto

Node.js is a cross-platform runtime environment and a set of libraries for server side applications written in JavaScript
== Runtime + Libraries + REPL + Package Manager

 V8 JavaScript runtime:
V8 is Google's open source JavaScript engine written in
C++ and used in Google's open source browser Chrome
 libuv:
A cross-platform library that abstracts OS host platform
system and: provides an event loop with callback based
notifications for Async I/O and other activities, timers,
non-blocking networking support, asynchronous file
system access, child processes and more.
 Non-blocking standard libraries:
Async + streams = highly concurrent, and it works well
for IO-bound workloads (but it is not parallelism).

REPL (read–eval–print loop)
provides a way to interactively run JavaScript and
see the results. It can be used for debugging, testing,
or just trying things out. It is available both as a
standalone program and easily embeddable in other
programs.

NPM is the official package manager for Node.js and is written entirely in JavaScript. It is bundled and installed
automatically with the environment. It has the command line interface and manages packages (modules)
dependencies for an application.
NPM enables you to install, publish, manage, and distribute JavaScript code easily

NPM install and uninstall commands

Not only for NodeJs, Browserify enables using NPM modules when developing for browser too!
Allows a node-style code organization when developing for browser and use of modules installed by NPM

Node.js provides the file system module, fs. For the most part, fs simply provides a wrapper for the standard file
operations. The following example uses the fs module to read contents of a file into memory

The HTTP interfaces in Node are designed to support many features of the protocol which have been traditionally
difficult to use. In particular, large, possibly chunk-encoded, messages. http module never buffers entire requests
or responses

 Single threaded / Async
I/O is provided by simple wrappers around standard POSIX functions. All the methods have asynchronous
and synchronous forms, but Async is default.
 Most APIs speak Streams:
The built-in stream module is used by the core libraries and can also be used by user-space modules, while
providing a backpressure mechanism to throttle writes for slow consumers
 Extensible via C/C++ add-ons:
Node.js is extensible and modules can include add-ons written in native code
 Local scope:
Browser JavaScript lifts everything into its global scope, Node.js was designed to have everything being local by
default. Exporting is done explicitly, and in case we need to access globals, there is a global object.

 Development efficiency
Web development in a dynamic language (JavaScript) and great package manager (NPM)
 Performant
Ability to handle thousands of concurrent connections with minimal overhead on a single process.
 Familiar
People already know how to use JavaScript, having used it in the browser.
 Full stack development
Using JavaScript on a web server as well as the browser reduces the impedance mismatch
between the two programming environments (+ JSON)

 What is Express.js?
 Hello World
 Request and Response
 Router
 Middleware

A minimal and flexible node.js web application framework, providing a robust set of features for building full web
applications and/or APIs.
• Middleware
• Routing
• Templating engines
• Layouts and partial views
• Environment-based configuration

http://adrianmejia.com/blog/2014/10/01/creating-a-restful-api-tutorial-with-nodejs-and-mongodb/

A router object is an isolated instance of middleware and routes, capable only of performing middleware and
routing functions.
A router behaves like middleware itself, so you can use it as an argument to app.use() or as the argument to
another router’s use() method.
Every Express application has a built-in app router:

Chainable route handlers for a route path can be created using app.route().
Since the path is specified at a single location, it helps to create modular routes and reduce redundancy and typos.

The express.Router class can be used to create modular mountable route handlers. A Router instance is a complete
middleware and routing system; for this reason it is often referred to as a “mini-app”
And then

Middleware is the core concept behind Express.js request processing and routing and is composed from any
number of functions that are invoked by the Express.js routing layer before final application request handler is
invoked.
 Application-level middleware
 Router-level middleware
 Error-handling middleware
 Built-in middleware
 Third-party middleware
Middleware function signature is simple:

Express.js has great built in capabilities to serve static content. The module is able to also gzip compress and/or
cache served files, too…
*As of 4.x, all of Express' previously included middleware are now in separate repositories. The only included
middleware is: express.static(), used to server static files.

Error-handling middleware are defined just like regular middleware, however must be defined with an arity of 4
signature: (error, request, response, next)

error-handling middleware are typically defined very last, below any other app.use() calls...

All of Express' previously (before v4.0) included middleware are now in separate repos. Here are some example
middleware modules:
 body-parser
 compression
 connect-timeout
 csurf
 errorhandler
 method-override
 morgan - previously logger
 response-time
 serve-favicon

 Koa
Koa is designed by the team behind Express, which aims to be a smaller, more
expressive, and more robust foundation for web applications and APIs.
Through leveraging generators Koa allows you to ditch callbacks and greatly
increase error-handling
 Restify
restify is a node.js module built specifically to enable you to build correct REST
web services. It intentionally borrows heavily from express as that is more or
less the de facto API for writing web applications on top of node.js.
 Hapi
hapi is a simple to use configuration-centric framework with built-in support
for input validation, caching, authentication, and other essential facilities for
building web and services applications.

 Hypermedia driven?
 Media types?
 Uniform interface?
 Stateless?

 Hypermedia driven?
 Media types?
http://events.layer7tech.com/state-api
 Stateless?
 Uniform interface?

roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Generic:
text/html
application/xml
application/json
Generic with hypermedia elements:
application/hal+json
application/json-ld
Domain Specific:
application/vnd.mymediatype-v2+json
Media Types define:
1. How is byte stream encoded and how to locate hypermedia elements
2. What the data represents
Format: type”/”subtype *(“;” parameter)
Used in: “Accept” and “ContentType” headers

Avoid generic media types (like JSON and XML) - they do not include hypermedia elements
Choice:
1) Use few (one?) generic media types with hypermedia elements
( to avoid the need for clients to understand too many )
+ the domain specific media types identified by a profile –
in the payload or in a HTTP header
or
2) Use many different domain specific media types?

HAL is designed for building APIs in which clients navigate around the resources by following links. Links are
identified by link relations, the lifeblood of a hypermedia API: they are how you tell client developers about what
resources are available and how they can be interacted with, and they are how the code they write will select
which link to traverse
HAL - Specification

The architectural properties affected by the constraints of the REST architectural style are:[4][6]
- Performance - component interactions can be the dominant factor in user-perceived performance and network efficiency.[7]
- Scalability to support large numbers of components and interactions among components. Roy Fielding, one of the principal
authors of the HTTP specification, describes REST's effect on scalability thus:
REST's client–server separation of concerns simplifies component implementation, reduces the complexity of connector
semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered
system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the
communication without changing the interfaces between components, thus allowing them to assist in communication
translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining
messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to
indicate semantics and exchange information, and responses explicitly indicate cacheability.[4]
Simplicity of interfaces
Modifiability of components to meet changing needs (even while the application is running)
Visibility of communication between components by service agents
Portability of components by moving program code with the data
Reliability is the resistance to failure at the system level in the presence of failures within components, connectors, or data[7]

 Uniform Interface
 Stateless
 Cacheable
 Client-Server
 Layered System
 Code on Demand (optional)

The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples
the architecture and enables each part to evolve independently. The four guiding principles of the uniform
interface are:
 Resource-Based
Individual resources are identified in requests using URIs as resource identifiers. The resources themselves are
conceptually separate from the representations that are returned to the client
 Manipulation of Resources Through Representations
When a client holds a representation of a resource, including any metadata attached, it has enough information
to modify or delete the resource on the server, provided it has permission to do so
 Self-descriptive Messages
Each message includes enough information to describe how to process the message. For example, which parser
to invoke may be specified by an Internet media type (previously known as a MIME type)
 Hypermedia as the Engine of Application State (HATEOAS)
HATEOS is the key constrain that makes web browsing possible. Applicable to APIs but not widely used. It is
simple to understand: each response message includes the links to next possible request message.

As REST is an acronym for REpresentational State Transfer, server statelessness is key.
Essentially, what this means is that the necessary state to handle the request is contained within the request
itself, whether as part of the URI, query-string parameters, body, or headers
Clients handle application state, servers resource state
Application state is information about where you are in the interaction that is used during your session with an
application.
Resource state is the kind of (semi-)permanent data a server stores, and lasts beyond the duration of a single session of
interactions.

The goal of caching is never having to generate the same response twice. The benefit of doing this is that we gain
speed and reduce server load.
 Expiration
 Expires header
 Cache-Control header
 Validation
 Last-Modified header
 ETag header

The client-server constraint is based on a principle known as the separation of concerns. It simply requires the
existence of a client component that sends requests and a server component that receives requests
Servers and clients may also be replaced and developed independently, as long as the interface is not altered

REST architecture is conceived as hierarchical layers of components, limited to communication with their
immediate neighbors.
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the
way.

The optional code-on-demand constraint allows clients to request and execute code from servers. This, in turn,
allows the server to deploy new features to clients. The result is improved extensibility and configurability for
servers, and improved performance and efficiency for clients

Level 0: Swamp of POX
tunnels requests and responses through its transport protocol,
using only one entry point (URI) and one kind of method (in HTTP,
this normally is the POST method). Examples of these are SOAP
and XML-RPC/JSON/RPC.
Level 1: Resources
This level uses multiple URIs, where every URI is the entry point to
a specific resource. Still, this level uses only one single method like
POST.
Level 2: (HTTP) verbs
This level suggests that in order to be truly RESTful, your API MUST
use limited set of verbs.
Level 3: Hypermedia controls
Level 3, the highest level, uses HATEOAS to deal with discovering
the possibilities of your API towards the clients.

 Granular (leads to CRUD)
 Not scalable
 Low level
 Chatty
 Business logic moves to consumer
 Coarse grained
 Focus on business entities vs activities
 Decoupled from internal domain implementation
 Business logic contained on th eserver side
*Use only GET and POST (CQRS)?

github.com/Srdjan/restoCode repository:

This presentation on GitHub: Building Killer RESTful APIs
Node.Js
 Mixu Online book
 Why Asynchronous?
 Mastering Node
Express
 Express Home Page
 Understanding Express.js
 A short guide to Connect Middleware
REST APIs
 REST API Tutorial
 Restful Exploration
 HAL - Hypertext Application Language

Building Killer RESTful APIs with NodeJs

More Related Content

What's hot

Similar to Building Killer RESTful APIs with NodeJs

Recently uploaded

Building Killer RESTful APIs with NodeJs