ne of the more tricky and debated topics in API circles is how to handle relational data. How deep into your data tree should it go, how to accept it from the client and how much to return to the client. One could choose to treat each resource as a silo and force the client to individually create each object and piece all of the relations together. However, that is not a great user experience. It also leads to a very large number of requests and data transfer, which has been a blemish on the idea of a REST API for a while. The emergence of modern mobile devices which limited bandwidth and performance profiles need a more streamlined

ne of the major components of a tastypie resource is the data preparation cycle, or hydration cycle. The hydration cycle is the aspect of a resource that is responsible for massaging raw user input into data objects suitable for saving to a data source, and vice versa.

The hydration cycle also encompasses the serialization machinery of the resource which is responsible for converting data object into standard data formats ( JSON, xml, etc ) and vice versa.

Serializtion Cycle

Each Tastypie resource has a Serializer instance which it uses internally to convert data between well formatted string and javascript objects. This behavior is defined in the serialize and deserialize resource methods A serializer class defines how
data is converted to and

ime series data is quickly becoming all the rage in big data circles. The primary use case for large amounts of time series data tends to be visualization of collected metrics. This could be the temperature of our house, CPU usage of a remote server, the oil levels of your car, etc. In a nut shell, time series data is:

• Data over a continuous time interval
• Data contains successive measurements across that interval
• Data uses equal spacing between every two consecutive measurements
• Each time unit within the interval has at most one data point

It might look something like this

[
    {
        time: '2016-01-01 00:00:00', // minute 0
        value: 1
    },{
        time: '2016-01-01 00:01:00', // minute 1
        value: 2
    }
]

The

hen you decide to open up parts of your API to the public, you will need to prepare for bad citizens, or consumers that may abuse your API. One way to safe guard against this might be throttling certain endpoints restricting them to a certain number of request per second.

Throttle ['Thraudl] -n --noun., -v --verb

1. a device controlling the flow
2. to choke or suffocate in any way.

Tastypie's base resource has hooks for easily implementing throttling behaviors. The default implementations are mostly for testing and debugging be provide the just such a behavior, allowing you to define a number of requests allowed during a given time frame. Setting up is very easy, and looks something like this:

Define

e have been taking a look at how to use Tastypie to easily create robust, feature rich REST APIs. Our focus has been on CRUD operations, mainly because they are the ones that ship with tastypie. However, we are not restricted to CRUD with tastypie. You can define any number of endpoints to do whatever you want. To create a custom set of endpoints there are three basic things you need to do:

• Define a route
• Define a handler
• Define Method Access

Last time we wrote a very simple resource that allowed use to just return simple objects. We are going to continue with that example by adding some custom routes to it. If you are joining in late,

ast time we took a look at setting up a pretty full featured REST api centered around Mongoose. However, sometimes simple is better. Maybe you don't want and/or need all of the extra things that the MongoResource in Tastypie provides. Sometimes you just want to get something, anything working and dump out some data. We don't need paging, caching, filtering, validation, etc. Luckily, Tastypie gives you a dead simple way to do this by simply defining the methods you want to support. Resource methods are defined as <HTTPVERB>_<ACTION>. So a dumb crud resource would look like this:

The Simple Resource

'use strict'
const {Resource} = require('tastypie')

const Simple = Resource.extend({
  get_list: function(

EST Apis seem to be taking over the world as of late, and Node has been the platform of choice for building them. However, when you take a look at some of the tooling for building robust REST APIs in the node community, the options are bleak at best. When you take a look at all of the properties that would make an API RESTful, it is easy to see that it is rather complex.

REST

There are a few fundamental properties that make apis RESTful - they should be a Scaleable, Stateless, Cacheable, fit into a Layered System which is apart of a Client / Server model that provides a Uniform Interface. In the confines of a Restful HTTP

one of the things that makes ghost great is it's almost forced simplicity. However, with that comes a bit of rigidity. If you want something more than the provided simplicity, you might find your self pulling your hair out. Search is one of the thing that is lacking from the default ghost set up. The last incarnation of my blog had everything indexed in a Xapian search index. I really wanted to bring back a local search index. Luckily, in the 0.5.x series, they pulled some string so that you can use ghost as a plain npm module. This means you can build your own app around ghost. This should make search possible.

Xapian is a search