Legacies

Large distributed systems often have different legacy services, or just old units of code, in their architecture. Having to deal with legacies usually involves carefully adapting the structure of an existing system while dealing with old platforms and backward-compatibility issues. Sometimes SOA design is even considered a possible approach for the maintenance of a large system.

In such situations, following REST patterns is certainly a big advantage. RESTful services communicate with one another by exposing uniform interfaces. Legacies can thus easily be “hidden” behind a REST connector that can translate messages between the legacy system and the REST architecture.

Heterogeneity

Heterogeneity is the property of having diverse  components in a system. Diversities are in a way unavoidable, no matter how hard you try: even in a monolithic and rather small application, as you try to scale that application it will reach a certain point where you will have to deal with diversity. Diversity can be seen as an emergent property of the process of scaling an application from blueprint design to production.

All large systems tend to become very heterogeneous, since different components and functions are developed with different purposes, at different times, with different technologies and programming languages (Figure 8-1). Scaling a system is hardly a harmonic process, although harmonization can help you in scaling your application.

Figure 8-1. An example of a small application using different repositories, open source libraries, databases, programming languages, operating systems, and cloud platforms

Generally speaking any distributed system, complex application, or code base, once it has grown to a certain size, will reach a point where maintenance and iterative feature development become a problem.

This happens for a number of reasons, including:

• The difficulty of rewriting part of the software or system
• The learning curve for new developers to start contributing to the project

This suggests that when a system component gets to a certain size, it becomes very difficult to add new features quickly. Furthermore, you cannot fix bugs quickly, and you cannot throw it away easily when it becomes obsolete, because rewriting the existing functionality might require a big investment of time and money.

So, when you have an opportunity to avoid having to deal with or even design very large components, you should always do that.

SOA paradigms would suggest decoupling complex systems into self-contained units that serve fewer functions and can be developed independently over time. In SOA terms, this is considered an investment.

In RESTful development we can apply the same paradigms and design simple APIs that serve a limited number of functions and communicate with one another to exchange information and messages.

Complexity

Large distributed systems are often very complex.  More importantly, they might be owned or maintained by different departments within an organization, or totally different companies. Integrating different systems may result in an added layer of complexity to overcome.

If each system, or application function, exposes a RESTful API, complexity can be resolved at the unit level and with almost total independence from the overall system design, as long as we ensure that the different units can continue communicating and exchanging information and messages.

Redundancy

Large systems all have a certain amount of redundancy. Some of this might just be accidental, but some might be intentional and managed, since not all data can be normalized and stored in a single place.

Integrating and consuming data that is spread across different heterogeneous systems is one of the problems shared by open applications that are sometimes operating on and sharing the same streams of data.

The Wikipin API

Wikipin is an application that returns geolocated Wikipedia articles based on the provided location or on the requesting client’s IP address.

Geolocated articles are provided from a database dump from Wikipedia, while the IP geolocation mechanism is based on MaxMind’s IP geolocation databases.

For this API application we are going to use rails-api with PostgreSQL and PostGIS. PostgreSQL is a popular object-relational database management system (ORDBMS) focused specifically on extensibility and standards compliance. It implements the majority of SQL standards and syntax, which will allow us to import the Wikipedia database dumps easily. Because we want to learn how to develop a platform of independent applications, we’ll take this opportunity to try a different DBMS. For this next application, we will use PostgreSQL.

We are also going to use PostGIS, for geographical queries. PostGIS is a spatial database extender for PostgreSQL: it adds support for geographic objects, enabling location queries to be run in SQL.

$ brew install postgres

$ brew install postgis

$ rails-api new wikipin

$ gem install pg

source 'https://rubygems.org'
gem 'rails', '4.1.4'
gem 'rails-api'
gem 'spring', :group => :development
gem 'pg' # PostgreSQL gem
# RGeo Active Record patched version
gem 'rgeo-activerecord',
:git => 'https://github.com/nopressurelabs/rgeo-activerecord',
:branch => 'master'
# Active record PostGIS adapter
gem 'activerecord-postgis-adapter'
# Serializer for JSON
gem 'active_model_serializers'

self.lonlat = Pin.rgeo_factory_for_column(:latlon)
.point(self.longitude, self.latitude)

self.lonlat = Pin.rgeo_factory_for_column(:latlon, {})
.point(self.longitude, self.latitude)

default: &default
encoding: utf-8
username: postgres
password: password5
pool: 5
timeout: 5000
su_username: postgres_su # a superuser for the database
su_password: # the superuser's password

$ sudo -u postgres psql postgres
# \password postgres
Enter new password:

$ createuser --interactive postgres_su
Shall the new role be a superuser? (y/n) y

development: <<: *default
adapter: postgis
database: wikipin_db_dev
postgis_extension: postgis # default is postgis
schema_search_path: public,postgis
test:
adapter: postgis
<<: *default
database: wikipin_db_test

Generating the models

At this point we are going to generate our models for the geolocated articles and our IP block and location objects.

The IP block object describes the IP address block and contains some information regarding the origin city and country (see Figure 8-4).

Figure 8-4. IP block table schema

We are going to use the Rails generator to generate the model class and migrations:

$ rails generate model block \
  network_start_ip:string network_prefix_length:integer \
  geoname_id:integer registered_country_geoname_id:integer \
  represented_country_geoname_id:integer postal_code:integer \
  "latitude:decimal{7,4}" "longitude:decimal{7,4}" \
--fixture false

The location table describes a city and its geographical information (Figure 8-5). It is used so that we can obtain the actual city where an IP block is located. The Location model and table won’t be used in this chapter.

Figure 8-5. Location table schema

Note

How would you use the Location model to further enhance the Wikipin API?

At this point we will generate the Location model and run the respective migrations:

$ rails generate model location \
  geoname_id:integer continent_code:string continent_name:string \
  country_iso_code:string country_name:string \
  subdivision_iso_code:string subdivision_name:string \
  city_name:string metro_code:integer time_zone:string \
  --fixture false

We will also need another model: the Pin model. From the database point of view, the pin table describes a geotagged Wikipedia article with its url corresponding to a Wikipedia page (Figure 8-6).

Figure 8-6. Pin table schema

We are now going to generate the Pin model as follows:

$ rails generate model pin \
  id:integer "longitude:decimal{17,14}" "latitude:decimal{17,14}" \
  title:string url:string \
  --fixture false

Once our models have been created we can run the rake tasks necessary to generate our database and run the migrations:

$ rake db:create db:migrate

Let’s familiarize ourselves a bit with our database by running a Postgres console and checking the results of our past actions:

$ psql

Once we are in the Postgres console, we can list all our databases:

\list

You should see the Wikipin development and test databases.

We can then connect to a specific database:

\c wikipin_db_dev

and list all the tables for the connected database:

\d

If we want to show a specific table we just have to run \d <table_name>:

\d blocks

Now we can copy the comma-separated values (CSV) dumps to our database:

COPY pins FROM '<full path>/wikipedia_articles_201107.csv' 
    DELIMITER ',' CSV;
COPY blocks FROM '<full path>/GeoLite2-City-Blocks.csv' 
    DELIMITER ',' CSV;
COPY locations FROM '<full path>/GeoLite2-City-Locations.csv'
    DELIMITER ',' CSV;

module GeoFactory
  extend ActiveSupport::Concern

  # The geo_factory function sets the actual latitude-longitude point
  # on the database column by using the values of latitude and
  # longitude.

  def geo_factory
    self.lonlat = self.class.rgeo_factory(self.longitude, 
                  self.latitude)
  end

# We define our class methods

module ClassMethods
  def rgeo_factory(longitude, latitude)
    self.rgeo_factory_for_column(:latlon).point(longitude, latitude)
  end

  # We define a find_near function to search records in a 
  # given radius

  def self.find_near(lon, lat, radius=0.5)
    factory = RGeo::Geographic.spherical_factory
    sw = factory.point(lon+radius, lat+radius)
    ne = factory.point(lon-radius, lat-radius)
    window = RGeo::Cartesian::BoundingBox
             .create_from_points(sw, ne).to_geometry
    self.where("lonlat && ?", window)
  end
end

class Foo
  def self.bar
    puts 'class method'
  end
  def baz
    puts 'instance method'
  end
end

Foo.bar # => "class method"
Foo.baz # => NoMethodError: undefined method 'baz' 
             for Foo:Class
Foo.new.baz # => instance method
Foo.new.bar # => NoMethodError: undefined method 'bar'
                 for #<Foo:0x1e820>

class Block < ActiveRecord::Base
  # We include the concern
  include GeoFactory

  # The following line sets a geographic implementation 
  # for the :lonlat column:
  set_rgeo_factory_for_column(:lonlat, 
           RGeo::Geographic.spherical_factory(:srid =&gt; 4326))

# And that is actually it!
end

module FindBlock
  extend ActiveSupport::Concern

  # This snippet of code is executed when the concern is included,
  # but only for the get_block action.

  included do
    before_filter :find_block, only: :get_block
  end

  # Here we set the IP address of the request. If the ip_address
  # param is present we use this; otherwise we use the request 
  # remote_ip.

  def set_ip
    if params[:ip_address]
      params[:ip_address]
    else
      request.remote_ip
    end
  end

  # Then we find the IP block corresponding to the IP address

  def find_block
    ip = set_ip

    # Here we do a bit of cosmetic work on the IP string because we 
    # actually want to find the block, not the single IP address. 
    # We remove the last part of the address (last octet) 
    # and replace it with 0.

    @block = Block.where(:network_start_ip => 
                        "::ffff:#{ip.rpartition(".")[0]}.0").first

  end

# And that's it!
end

$ rails g controller api/v1/block

class Api::V1::BlocksController < ApplicationController

  # Include the concern

  include FindBlock

  # Use JSON

  respond_to :json

  # Find the block by ID.
  # If a block is found, render JSON through the serializer;
  # else render an error. We are going to define both the serializer
  # and the error object later.

  def show
    @block = Block.find(params[:id])
    if @block
      render :json => @block, serializer: BlockSerializer,
        root: "ip_block"
    else
      @error = Error.new(:text => "404 Not found", :status => 404, 
        :url => request.url, :method => request.method)
      render :json => @error.serializer
    end
  end

  # The block of this method is fetched through the concern.
  # If found it is serialized and rendered; otherwise an error is
  # returned.

  def get_block
    if @block
      render :json => @block, serializer: BlockSerializer, 
        root: "ip_block"
    else
      @error = Error.new(:text => "404 Not found", :status => 404, 
        :url => request.url, :method => request.method)
      render :json => @error.serializer
    end
  end

# And that is it!
end

class Error

  # ActiveModel::Validations provides a full validation framework
  # to your objects; ActiveModel::Conversion handles default
  # conversions #to_model, #to_key, #to_param, and #to_partial_path;
  # and finally ActiveModel::Naming creates a model_name method on
  # your object.

  include ActiveModel::Validations
  include ActiveModel::Conversion
  extend ActiveModel::Naming

  # We need to define the set of attributes that can be accessed.
  # The method attr_accessor defines a named attribute for the
  # module and creates an instance variable (@name) and a
  # corresponding access method to read it.
  # It also creates a method called name= to set the attribute.

  attr_accessor :text, :status, :url, :method

  def _links
    {:url => request, :entry => entry}
  end

  # This method serializes the request object

  def request
    href = URI::encode(url)
    {:href => href, :method => method, :rel => "request"}
  end

  # This method specifies a default entry point to return to 
  # the client

  def entry
    href = URI::encode("/api/v1")
    {:href => href, :method => "GET", :rel => "entry point", 
     :params => params}
  end

  # Here is how we display the params submitted through the query

  def params
    {:point => {:value => "{lon},{lat}", :optional => true}, 
     :title => {:value => "text", :optional => true}}
  end

  # The following method serializes the error object

  def serializer
    {:error => {:url => url, :text => text, :status => status, 
     :method => method, :_links => _links }}
  end

  # Here the error object and its attributes are initialized

  def initialize(attributes = {})
    attributes.each do |name, value|
      send("#{name}=", value)
    end
  end

  # Here we just define the object as nonpersisted; 
  # therefore we are not saving it to the database.

  def persisted?
    false
  end

# And that's it!
end

module EntryFiltering
  extend ActiveSupport::Concern

  # We want to perform only the entry_action for the index method

  included do
    before_filter :entry_action, only: :index
  end

  # point is a string containing geographical coordinates in 
  # the form {logitude},{latitude}

  def pins_by_point(point)
    point = point.split(',')
    @pins = Pin.find_near(point[0].to_f, point[1].to_f)
  end

  # If no coordinates are sent, we will try to locate the IP 
  # and retrieve pins close to the IP location

  def pins_by_ip(ip)
    block = Block.where(:network_start_ip => 
                        "::ffff:#{ip.rpartition(".")[0]}.0").first
    if block
      Pin.find_near(block.longitude.to_f, block.latitude.to_f)
    end
  end

  # Finally, our entry_action fetches pins by IP if no 
  # point param is provided

  def entry_action
    if params[:point]
      @pins = pins_by_point(params[:point])
    else
      @pins = pins_by_ip(request.remote_ip)
    end
  end

# And that's it.
end

 class Api::V1::PinsController < ApplicationController

  include EntryFiltering
  respond_to :json

  # Here we display the pins fetched by location. 
  # If no pins are provided we send an error:

  def index
    if @pins
      render :json => @pins, each_serializer: PinSerializer, 
        root: "pins"
    else
      @error = Error.new(:text => "404 Not found", 
        :status => 404, :url => request.url, 
        :method => request.method)
      render :json => @error.serializer
    end
  end

  # Finally we find the pin by ID and return it serialized.
  # If no pin is found, we return an error:

  def show
    @pin = Pin.find(params[:id])
    if @pin
      render :json => @pin, serializer: PinSerializer, root: "pin"
    else
      @error = Error.new(:text => "404 Not found", 
        :status => 404, :url => request.url, 
        :method => request.method)
      render :json => @error.serializer
    end
  end

# And that is it.
end

The Citywalks API

The Citywalks API is a service that returns and creates geolocated routes within a certain location radius. It uses the Wikipin API to discover Wikipedia articles that are geolocated nearby and connects them in a possible route that the user can walk. Each article contains category information, so users could potentially create thematic walks related to specific categories. We will explore this aspect in the next chapter, when we will venture into creating a proper web application using the APIs that we have been developing up to this point.

The Citywalks API will be a rails-api application and will use MongoDB as a database. MongoDB (from “humongous”) is an open source document database written in C++.

So what is a document database? A document database uses documents instead of tables. Documents are like objects, and they map nicely to programming language data types; also, embedded documents and arrays reduce the need for join operations, and using a dynamic schema makes polymorphism easier. A MongoDB deployment hosts a number of databases. A database holds a set of collections. A collection holds a set of documents. A MongoDB collection is similar to a SQL table. A document is a set of key/value pairs and can be compared to a record in a SQL table. We also said that documents have a dynamic schema. This means that documents in the same collection do not need to have the same set of fields or structure, and common fields in a collection’s documents may hold different types of data.

The object document mapper (ODM) for MongoDB that we will use is Mongoid (pronounced mann-goyd).

To create a Rails API application with Mongoid, we need to tell Rails to skip Active Record, since Mongoid will take its place:

$ rails-api new citywalks --skip-active-record

This will insert the following lines into config/application.rb:

require "active_model/railtie"
# require "active_record/railtie"
require "action_controller/railtie"
require "action_mailer/railtie"
require "action_view/railtie"
require "sprockets/railtie"
require "rails/test_unit/railtie"

Finally, we edit the Gemfile:

source 'https://rubygems.org'
gem 'rails', '4.1.4'

# Patched locally because of issue:
# https://github.com/rails-api/rails-api/issues/142

gem 'rails-api',
  :git => 'https://github.com/nopressurelabs/rails-api',
  :branch => 'master'

gem 'moped', github: 'mongoid/moped'
gem 'mongoid', '~> 4.0.0', github: 'mongoid/mongoid'
gem 'bson_ext'

gem 'spring', :group => :development

# Serializer for JSON
gem 'active_model_serializers'

# CORS
gem 'rack-cors', :require => 'rack/cors'

It is time to initialize our application. First we bundle:

$ bundle install

Then we run:

$ rake db:create

Discovering the /lib Directory

The Citywalks API will use the WikiCat API to find categories about pins and the Wikipin API to actually find pins nearby.

To fetch data from external sources we will have to write some logic that will make a REST call fetch and parse some data. The code that we are going to need to do this is not strictly related to our core app. It does not belong to our models or our controllers, nor does it extend them.

This code lives in the /lib directory.

The first module that we are going to write is going to handle REST requests and responses, while also creating meaningful errors in case something goes wrong. Create a new document under /lib called restful.rb and define it as follows:

require 'net/http'
require 'json'

module Restful

  def send_request(end_point)
    request_url = URI.parse(URI.encode(end_point))
    log "Request URL: #{request_url}"
    res = Net::HTTP.get_response(request_url)
    unless res.kind_of? Net::HTTPSuccess
      raise Restful::RequestError, "HTTP Response: #{res.code} #{res.message}"
    end
    Response.new(res.body)
  end

  class RequestError < StandardError; end

  # Response object returned after REST call to service.

  class Response

    def initialize(json)
      @doc = JSON.parse(json)
    end

    # Return JSON object.
    def doc
      @doc
    end

    # Return true if response has an error.
    def has_error?
      !(error.nil? || error.empty?)
    end

    # Return error message.

    def error
      @doc.has_key? "error"
    end

    # Return error code.

    def error_code
      if @doc.has_key? "error"
        @doc["error"]["status"]
      end
    end
  end

  protected

  def log(s)
    if defined? RAILS_DEFAULT_LOGGER
      RAILS_DEFAULT_LOGGER.error(s)
    elsif defined? LOGGER
      LOGGER.error(s)
    else
      puts s
    end
  end
end

Now we are going to define two similar modules: one for the Wikipin API and one for the WikiCat API.

We will start by creating a wikicat.rb file under /lib, defined as follows:

require 'net/http'
require 'json'

module Wikicat
  # Here we define the API version and the endpoints 
  # we are going to use

  CAT_VERSION = '1.0'
  CAT_SERVICE_URL = 'http://0.0.0.0:3000'
  PIN_SERVICE_URL = 'http://wikipin-nopressurelabs.rhcloud.com'

  # Given a pin's relative URL will get the pin's upper category graph

  def pin_upper(pin)
    get_pin = self.class.send_request("#{PIN_SERVICE_URL}#{pin}")
    cat = get_pin.doc["pin"]
    if cat
      sub_category = cat["title"]
      request_upper_graph(sub_category).doc[sub_category]
    end
  end

  # Given a pin's relative URL will get the pin's lower category graph

  def pin_lower(pin)
    get_pin = send_request("#{PIN_SERVICE_URL}#{pin}")
    cat = get_pin.doc["pin"]
    if cat
      sub_category = cat["title"]
      request_lower_graph(sub_category).doc[sub_category]
    end
  end

  # Fetch the actual upper category graph

  def request_upper_graph(category)
    self.class.send_request("#{CAT_SERVICE_URL}/api/v1/graph/up/
      #{category.gsub!(/\s/,'_')}")
  end

  # Fetch the actual lower category graph
  def request_lower_graph(category)
    self.class.send_request("#{CAT_SERVICE_URL}/api/v1/graph/
      #{category.gsub!(/\s/,'_')}")
  end
end

Now we will create a wikipin.rb file under /lib, defined as follows:

require 'net/http'
require 'json'

module Wikipin

  PIN_VERSION = '1.0'
  PIN_SERVICE_URL = 'http://wikipin-nopressurelabs.rhcloud.com'

  # Here we make the call to get the pins available for our 
  # position.
  # We can either provide a point with latitude and longitude 
  # or have the service locate us through our IP address.

  def request_pins(point=nil)
    # point = "lon,lat"
    if point
      send_request("#{PIN_SERVICE_URL}/api/v1/pins/?point=#{point}")
    else
      send_request("#{PIN_SERVICE_URL}/api/v1/pins")
    end
  end

  # Here we request the IP address block information
  def request_block(ip)
    send_request("#{PIN_SERVICE_URL}/api/v1/blocks?ip_address=#{ip}")
  end

  # Here we simply get the pin
  def get_pin(pin)
    send_request("#{PIN_SERVICE_URL}#{pin}")
  end
end

The /lib directory is a great place to start testing code that you would like to extract from the app, and eventually into a Ruby gem. Moving code there allows you to test it in isolation. Also, this forces you to write the code as an independent class from your app. Then, if you are satisfied with what you have obtained, you can easily extract it into an external gem.

Defining the Models

Now that we’ve defined the build logic, we can go back to our app to define our actual models.

The first model that we are going to need is a Walk model. We will start by creating a walk.rb file under app/models:

class Walk
  include Mongoid::Document
  include Mongoid::Timestamps::Created
  include ActiveModel::SerializerSupport

  # Remember the difference between extend and include?

  extend Wikipin
  extend Restful
  include Wikicat

  # These are the fields that the Walk model contains.

  field :title, type: String
  field :author, type: String
  field :pins, type: Array
  field :location, :type => Array
  field :categories, :type => Array

  index({ location: "2d" }, { min: -200, max: 200 })

  validates :pins, length: { minimum: 0, maximum: 10 }

end

Then we create the index in our database dynamically by just running:

$ rake db:mongoid:create_indexes

We also need to define a nonpersistent error object. It will be identical to the error object defined earlier in this chapter, so I will not repeat the same code (you can find the code in the repository).

Building the Controllers

The walks controller will allow us to perform all the CRUD operations on the walk resource. We want to be able to list all the walks, create walks, delete walks, and modify walks:

class Api::V1::WalksController < ApplicationController
  respond_to :json

  # Here we include two concerns that will be defined later on
  # and will be used to create and locate walks.

  include WalkLocator
  include WalkCreator

  # before_action is a filter.
  # Filters are methods that are run before, 
  # after, or "around" a controller action.
  # Filters are inherited, so if you set a filter on
  # ApplicationController, it will be run on every controller 
  # in your application.

  before_action :set_walk, only: [:show, :edit, :update, :destroy]

  def index
    if @walks
      render :json => @walks.to_a, each_serializer: WalkSerializer, 
        root: "walks"
    else
      @error = Error.new(:text => "404 Not found",
        :status => 404, :url => request.url, 
        :method => request.method)
      render :json => @error.serializer
    end
  end

  # GET /walks/1
  # GET /walks/1.json
  def show
    if @walk
      render :json => @walk, serializer: WalkSerializer, 
        root: "walk"
    else
      @error = Error.new(:text => "404 Not found", 
        :status => 404, :url => request.url, 
        :method => request.method)
      render :json => @error.serializer
    end
  end

  # GET /walks/1/edit
  def edit

  end

  # GET /walks/new
  def new
    @walk = Walk.new
  end

  # POST /walks
  # POST /walks.json
  def create
    @walk = initialize_walk(walk_params)
    if @walk.save
      render :json => @walk, serializer: WalkSerializer, 
      root: "walk"
    else
      render :json => @walk.errors
    end
  end

  # PATCH/PUT /walks/1
  # PATCH/PUT /walks/1.json
  def update
    if @walk.update(walk_params)
      render :json => @walk, serializer: WalkSerializer, 
        root: "walk"
    else
      render :json => @walk.errors
    end
  end

  # DELETE /walks/1
  # DELETE /walks/1.json
  def destroy
    if @walk.destroy
      render :json => { :head => ok }
    else
      render :json => @walk.errors
    end
  end

  private

  # Use callbacks to share common setup or constraints
  # between actions.
  def set_walk
    @walk = Walk.find(params[:id])
  end

  # Never trust parameters from the scary Internet; 
  # only allow the whitelist through.
  def walk_params
    params.require(:walk).permit(:title, 
                                 :author, 
                                 :location, 
                                 :pins, 
                                 :categories)
  end
end

Now we define the concerns that we have included in our controller. The first one will be used to locate walks:

module WalkLocator
  extend ActiveSupport::Concern

  included do
    before_filter :entry_action, only: [:index]
  end

  def walks_by_point(point)
    point = point.split(",")
    @walks = Walk.geo_near([ point[0].to_f, point[1].to_f ])
             .spherical
  end

  def walks_by_ip(ip)
    if ip = "127.0.0.1"
      walks_by_point("41.23,2.09")
    else
      block = Walk.request_block(ip).doc["ip_block"]
      if block
        longitude = block["point"].scan(/\(([^\)]+)\)/)
          .last.first.split(" ")[0]
        latitude = block["point"].scan(/\(([^\)]+)\)/)
          .last.first.split(" ")[1]
        Walk.geo_near([ longitude.to_f, latitude.to_f ]).spherical
      end
    end
  end

  def entry_action

    if params[:location]
      @walks = walks_by_point(params[:location])
    else
      @walks = walks_by_ip(request.remote_ip)
    end
  end
end

The second concern will be used to create walks:

module WalkCreator
  extend ActiveSupport::Concern

  def initialize_walk(params)
    params[:location] = set_location(params[:location])
    params[:pins] = params[:pins].split(",")
    Walk.new(params)
  end

  def set_location(location)
    if location
      location = location.split(",")
      [location[0].to_f, location[1].to_f]
    else
      block = retrieve_position(request.remote_ip)
      if block
        longitude = block["point"].scan(/\(([^\)]+)\)/)
          .last.first.split(" ")[0]
        latitude = block["point"].scan(/\(([^\)]+)\)/)
           .last.first.split(" ")[1]
        [longitude.to_f, latitude.to_f ]
      end
    end
  end

  def retrieve_position(ip)
    Walk.request_block(ip).doc["ip_block"]
  end
end

Now if everything is working as expected we will be able to make a POST request to our API and actually create a walk with some test pins:

$ curl --data "walk \
  [author]=<username>&walk[title]=first-walk& \
  walk[location]=2.09,41.23& \
  walk[pins]=/api/v1/pins/27,/api/v1/pins/28" \
  http://0.0.0.0:3001/api/v1/walks