Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/mattt/sinatra-param

Parameter Validation & Type Coercion for Sinatra
https://github.com/mattt/sinatra-param

coercion parameters ruby sinatra validation

Last synced: about 2 months ago
JSON representation

Parameter Validation & Type Coercion for Sinatra

Awesome Lists containing this project

README 

        
# sinatra-param



_Parameter Validation & Type Coercion for Sinatra_



REST conventions take the guesswork out of designing and consuming web APIs. Simply `GET`, `POST`, `PATCH`, or `DELETE` resource endpoints, and you get what you'd expect.



However, when it comes to figuring out what parameters are expected... well, all bets are off.



This Sinatra extension takes a first step to solving this problem on the developer side



**`sinatra-param` allows you to declare, validate, and transform endpoint parameters as you would in frameworks like [ActiveModel](http://rubydoc.info/gems/activemodel/3.2.3/frames) or [DataMapper](http://datamapper.org/).**



> Use `sinatra-param` in combination with [`Rack::PostBodyContentTypeParser` and `Rack::NestedParams`](https://github.com/rack/rack-contrib) to automatically parameterize JSON `POST` bodies and nested parameters.



## Install



You can install `sinatra-param` from the command line with the following:



```bash

$ gem install sinatra-param

```



Alternatively, you can specify `sinatra-param` as a dependency in your `Gemfile` and run `$ bundle install`:



```ruby

gem "sinatra-param", require: "sinatra/param"

```



## Example



```ruby

require 'sinatra/base'

require 'sinatra/param'

require 'json'



class App < Sinatra::Base

  helpers Sinatra::Param



  before do

    content_type :json

  end



  # GET /search?q=example

  # GET /search?q=example&categories=news

  # GET /search?q=example&sort=created_at&order=ASC

  get '/search' do

    param :q,           String, required: true

    param :categories,  Array

    param :sort,        String, default: "title"

    param :order,       String, in: ["ASC", "DESC"], transform: :upcase, default: "ASC"

    param :price,       String, format: /[<\=>]\s*\$\d+/



    one_of :q, :categories



    {...}.to_json

  end

end

```



### Parameter Types



By declaring parameter types, incoming parameters will automatically be transformed into an object of that type. For instance, if a param is `Boolean`, values of `'1'`, `'true'`, `'t'`, `'yes'`, and `'y'` will be automatically transformed into `true`.



* `String`

* `Integer`

* `Float`

* `Boolean` _("1/0", "true/false", "t/f", "yes/no", "y/n")_

* `Array` _("1,2,3,4,5")_

* `Hash` _(key1:value1,key2:value2)_

* `Date`, `Time`, & `DateTime`



### Validations



Encapsulate business logic in a consistent way with validations. If a parameter does not satisfy a particular condition, a `400` error is returned with a message explaining the failure.



* `required`

* `blank`

* `is`

* `in`, `within`, `range`

* `min` / `max`

* `min_length` / `max_length`

* `format`



### Custom Error Messages



Passing a `message` option allows you to customize the message

for any validation error that occurs.



```ruby

param :spelling,

      format: /\b(?![a-z]*cie)[a-z]*(?:cei|ie)[a-z]*/i,

      message: "'i' before 'e', except after 'c'"

```



### Defaults and Transformations



Passing a `default` option will provide a default value for a parameter if none is passed. A `default` can defined as either a default or as a `Proc`:



```ruby

param :attribution, String, default: "©"

param :year, Integer, default: lambda { Time.now.year }

```



Use the `transform` option to take even more of the business logic of parameter I/O out of your code. Anything that responds to `to_proc` (including `Proc` and symbols) will do.



```ruby

param :order, String, in: ["ASC", "DESC"], transform: :upcase, default: "ASC"

param :offset, Integer, min: 0, transform: lambda {|n| n - (n % 10)}

```



## One Of



Using `one_of`, routes can specify two or more parameters to be mutually exclusive, and fail if _more than one_ of those parameters is provided:



```ruby

param :a, String

param :b, String

param :c, String



one_of :a, :b, :c

```



## Any Of



Using `any_of`, a route can specify that _at least one of_ two or more parameters are required, and fail if _none of them_ are provided:



```ruby

param :x, String

param :y, String



any_of :x, :y

```



## All Or None Of



Using `all_or_none_of`, a router can specify that _all_ or _none_ of a set of parameters are required, and fail if _some_ are provided:



```ruby

param :x, String

param :y, String



all_or_none_of :x,:y

```



### Exceptions



By default, when a parameter precondition fails, `Sinatra::Param` will `halt 400` with an error message:



```json

{

  "message": "Parameter must be within [\"ASC\", \"DESC\"]",

  "errors": {

    "order": "Parameter must be within [\"ASC\", \"DESC\"]"

  }

}

```



To change this, you can set `:raise_sinatra_param_exceptions` to `true`, and intercept `Sinatra::Param::InvalidParameterError` with a Sinatra `error do...end` block. (To make this work in development, set `:show_exceptions` to `false` and `:raise_errors` to `true`):



```ruby

set :raise_sinatra_param_exceptions, true



error Sinatra::Param::InvalidParameterError do

    { error: "#{env['sinatra.error'].param} is invalid" }.to_json

end

```



Custom exception handling can also be enabled on an individual parameter basis, by passing the `raise` option:



```ruby

param :order, String, in: ["ASC", "DESC"], raise: true



one_of :q, :categories, raise: true

```



## Contact



Mattt ([@mattt](http://twitter.com/mattt))



## License



sinatra-param is released under an MIT license. See LICENSE for more information.