You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Welcome to the `frontier` branch. This is where we're experimenting and building the next version of Grape. Things will be civilized here one day, but until then you best carry your revolver with you.**
4
4
5
-
Grape is a REST-like API micro-framework for Ruby. It is built to complement existing web application frameworks such as Rails and Sinatra by providing a simple DSL to easily provide APIs. It has built-in support for common conventions such as multiple formats, subdomain/prefix restriction, and versioning.
5
+
## What is Grape?
6
+
7
+
Grape is a REST-like API micro-framework for Ruby. It is built to complement
8
+
existing web application frameworks such as Rails and Sinatra by providing a
9
+
simple DSL to easily provide APIs. It has built-in support for common
10
+
conventions such as multiple formats, subdomain/prefix restriction, and
11
+
versioning.
12
+
13
+
## Project Tracking
14
+
15
+
*[Grape Google Group](http://groups.google.com/group/ruby-grape)
@@ -12,7 +23,9 @@ Grape is available as a gem, to install it just install the gem:
12
23
13
24
## Basic Usage
14
25
15
-
Grape APIs are Rack applications that are created by subclassing `Grape::API`. Below is a simple example showing some of the more common features of Grape in the context of recreating parts of the Twitter API.
26
+
Grape APIs are Rack applications that are created by subclassing `Grape::API`.
27
+
Below is a simple example showing some of the more common features of Grape in
28
+
the context of recreating parts of the Twitter API.
16
29
17
30
```ruby
18
31
classTwitter::API < Grape::API
@@ -61,7 +74,8 @@ class Twitter::API < Grape::API
61
74
end
62
75
```
63
76
64
-
This would create a Rack application that could be used like so (in a Rackup config.ru file):
77
+
This would create a Rack application that could be used like so (in a Rackup
By default, the first matching version is used when no Accept header is supplied. This behavior is similar to routing in Rails.
86
-
To circumvent this default behaviour, one could use the `:strict` option. When this option is set to `true`, a `404 Not found` error is returned when no correct Accept header is supplied.
99
+
By default, the first matching version is used when no Accept header is
100
+
supplied. This behavior is similar to routing in Rails.
101
+
To circumvent this default behaviour, one could use the `:strict` option. When
102
+
this option is set to `true`, a `404 Not found` error is returned when no
103
+
correct Accept header is supplied.
87
104
88
-
Serialization takes place automatically. For more detailed usage information, please visit the [Grape Wiki](http://github.com/intridea/grape/wiki).
105
+
Serialization takes place automatically. For more detailed usage information,
106
+
please visit the [Grape Wiki](http://github.com/intridea/grape/wiki).
89
107
90
108
## Helpers
91
109
@@ -117,39 +135,6 @@ class API < Grape::API
117
135
end
118
136
````
119
137
120
-
121
-
## Working with Entities
122
-
123
-
A common problem in designing Ruby APIs is that you probably don't want
124
-
the exact structure of your data models exposed. ActiveRecord, for
125
-
instance, will dump all of its attributes. While you can override
126
-
`#as_json` to alter this behavior somewhat, what is really needed is an
127
-
intermediary layer between the model and the API. This is where the
@@ -183,15 +169,17 @@ class Twitter::API < Grape::API
183
169
end
184
170
```
185
171
186
-
The error format can be specified using `error_format`. Available formats are `:json` and `:txt` (default).
172
+
The error format can be specified using `error_format`. Available formats are
173
+
`:json` and `:txt` (default).
187
174
188
175
```ruby
189
176
classTwitter::API < Grape::API
190
177
error_format :json
191
178
end
192
179
```
193
180
194
-
You can rescue all exceptions with a code block. The `rack_response` wrapper automatically sets the default error code and content-type.
181
+
You can rescue all exceptions with a code block. The `rack_response` wrapper
182
+
automatically sets the default error code and content-type.
195
183
196
184
```ruby
197
185
classTwitter::API < Grape::API
@@ -201,7 +189,8 @@ class Twitter::API < Grape::API
201
189
end
202
190
```
203
191
204
-
You can also rescue specific exceptions with a code block and handle the Rack response at the lowest level.
192
+
You can also rescue specific exceptions with a code block and handle the Rack
193
+
response at the lowest level.
205
194
206
195
```ruby
207
196
classTwitter::API < Grape::API
@@ -220,9 +209,22 @@ end
220
209
end
221
210
end
222
211
212
+
## Content-Types
213
+
214
+
By default, Grape supports _XML_, _JSON_, _Atom_, _RSS_, and _text_ content-types. Your API can declare additional types to support. Response format is determined by the request's extension or `Accept` header.
215
+
216
+
```ruby
217
+
classTwitter::API < Grape::API
218
+
content_type :xls, "application/vnd.ms-excel"
219
+
end
220
+
```
221
+
223
222
## Writing Tests
224
223
225
-
You can test a Grape API with RSpec. Tests make HTTP requests, therefore they must go into the `spec/request` group. You may want your API code to go into `app/api` - you can match that layout under `spec` by adding the following in `spec/spec_helper.rb`.
224
+
You can test a Grape API with RSpec. Tests make HTTP requests, therefore they
225
+
must go into the `spec/request` group. You may want your API code to go into
226
+
`app/api` - you can match that layout under `spec` by adding the following in
227
+
`spec/spec_helper.rb`.
226
228
227
229
```ruby
228
230
RSpec.configure do |config|
@@ -250,7 +252,8 @@ end
250
252
251
253
## Describing and Inspecting an API
252
254
253
-
Grape lets you add a description to an API along with any other optional elements that can also be inspected at runtime.
255
+
Grape lets you add a description to an API along with any other optional
256
+
elements that can also be inspected at runtime.
254
257
This can be useful for generating documentation.
255
258
256
259
```ruby
@@ -272,7 +275,11 @@ class TwitterAPI < Grape::API
272
275
end
273
276
```
274
277
275
-
Grape then exposes arrays of API versions and compiled routes. Each route contains a `route_prefix`, `route_version`, `route_namespace`, `route_method`, `route_path` and `route_params`. The description and the optional hash that follows the API path may contain any number of keys and its values are also accessible via dynamically-generated `route_[name]` functions.
278
+
Grape then exposes arrays of API versions and compiled routes. Each route
279
+
contains a `route_prefix`, `route_version`, `route_namespace`, `route_method`,
280
+
`route_path` and `route_params`. The description and the optional hash that
281
+
follows the API path may contain any number of keys and its values are also
282
+
accessible via dynamically-generated `route_[name]` functions.
StringAPI::routes[0].route_optional_params # yields an array [ "limit" ]
295
302
```
296
303
304
+
## Anchoring
305
+
306
+
Grape by default anchors all request paths, which means that the request URL
307
+
should match from start to end to match, otherwise a `404 Not Found` is
308
+
returned.
309
+
However, this is sometimes not what you want, because it is not always known up
310
+
front what can be expected from the call.
311
+
This is because Rack-mount by default anchors requests to match from the start
312
+
to the end, or not at all. Rails solves this problem by using a `:anchor =>
313
+
false` option in your routes.
314
+
In Grape this option can be used as well when a method is defined.
315
+
316
+
For instance when you're API needs to get part of an URL, for instance:
317
+
318
+
```ruby
319
+
classUrlAPI < Grape::API
320
+
namespace :urlsdo
321
+
get '/(*:url)', :anchor => falsedo
322
+
some_data
323
+
end
324
+
end
325
+
end
326
+
```
327
+
328
+
This will match all paths starting with '/urls/'. There is one caveat though:
329
+
the `params[:url]` parameter only holds the first part of the request url.
330
+
Luckily this can be circumvented by using the described above syntax for path
331
+
specification and using the `PATH_INFO` Rack environment variable, using
332
+
`env["PATH_INFO"]`. This will hold everyting that comes after the '/urls/'
333
+
part.
334
+
297
335
## Note on Patches/Pull Requests
298
336
299
-
* Fork the project.
300
-
* Make your feature addition or bug fix.
301
-
* Add tests for it. This is important so I don't break it in a future version unintentionally.
302
-
* Commit, do not mess with Rakefile, version, or history. (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
303
-
* Send me a pull request. Bonus points for topic branches.
337
+
* Fork the project
338
+
* Write tests for your new feature or a test that reproduces a bug
339
+
* Implement your feature or make a bug fix
340
+
* Do not mess with Rakefile, version or history
341
+
* Commit, push and make a pull request. Bonus points for topical branches.
342
+
343
+
## License
344
+
345
+
MIT License. See LICENSE for details.
304
346
305
347
## Copyright
306
348
307
-
Copyright (c) 2010 Michael Bleigh and Intridea, Inc. See LICENSE for details.
349
+
Copyright (c) 2010-2012 Michael Bleigh and Intridea, Inc.
0 commit comments