This is the second post on the Service Design Patterns in Rails. The first one was about Client-Service Interaction styles patterns. This one is about Request and Response Management patterns (from the book Service Design Patterns by Robert Daigneau).
The Request and Response Management patterns are:
- Service Controller
- Data Transfer Object
- Request Mapper
- Response Mapper
Service Controller pattern means that there is a class that decides which controller should be called. The decision is made based on the Request (for example "GET /customer/123") and a set of rules.
Does it sound familiar? Yes! This is the routes.rb file. Here is the simplest rule of all:
resources :products
which means, any request to /products will be routed to the products controller.
The Data Transfer Object is an intermediate object used in the request or the response instead of using the domain objects. That is, instead of serializing the Products object on the typical rails example, you would instead use another object populated from the values in the Product.
On the request side, this is achieved through the params object. See this code which is typically in the typical Products controller example:
def set_product
@product = Product.find(params[:id])
end
@product = Product.find(params[:id])
end
this is how we find in the database a product with id "params[:id]".
"params[:id]" is the 123 from "GET products/123" request.
Another example, when we want to update, how we update it with the params object:
def update
respond_to do |format|
if @product.update(params)
....
else
...
end
end
end
However, in the response side I have bad news. A rails typical application is not using a Data Transfer Object. See the typical example:
class ProductsController < ApplicationController
def index
@products = Products.all
respond_to do |format|
format.json { render json @products}
end
end
end
end
This code means that the object used in the response, is the Products object serialized as json. Under the hoods, the "ActiveRecord::to_json" call is made for this purpose. This means that the response is highly coupled with the domain object.
What we should do instead is rendering the response in the view, by using a template.
Rails does come with builder for "xml templating". If we were using xml
for the response, the following code will work as long as we had an
index.xml.builder file.
class ProductsController < ApplicationController
def index
@products = Products.all
respond_to do |format|
format.xml
end
end
end
end
Thus, for json to work, we would expect something like:
class ProductsController < ApplicationController
def index
@products = Products.all
respond_to do |format|
format.json
end
end
end
end
However, rails does not come by default with "json templating" and thus the previous code won't work unless we add some "json templating" gem.
Researching a bit on google, I've found this post that explains the case very well and much better than I could and gives some options on "json templating":
Finally, Request and Response Mapper are two patterns that can be used to interact with different web services, different on the syntax, but semantically equivalent. In that situation, you need an object that maps different request/responses to the same controller.
In the case of the Request Mapper, we get back to the routes.rb file, where you can declare matching patterns. For example if you were authenticating against github, you may have this line on your routes.rb file
get "/auth/:provider/callback" => "sessions#create"
The Response Mapper is used to construct a response but used by different web services. This can be used when you need to create a response that matches some kind of agreement between different parties. Sadly I don't know of a typical rails example that does that. If you know one, please tell me.
Posts
1 comment:
Appreciate you blogging thhis
Post a Comment