Grape vs. Poncho
The Integration Zone is brought to you in partnership with Red Hat. Download the IDC Report: The Business Value of Red Hat Integration Products to learn more about Red hat Integration.
With Poncho you start by declaring resources that inherit from Poncho::Resource. A resource is a prescriptive way of declaring what parameters to expect and what results to render from the API. In many ways resources are similar to Grape’s entities, except that the latter are no longer part of Grape and you can use roar, rabl or any other framework to render results - you choose. Poncho resources include parameter validation, which makes sense. Personally, language matters, so I would not call values that can be assigned to the resource parameters, but maybe fields or attributes.
You then declare a Poncho::JSONMethod, which inherits from Poncho::Method, which is a piece of middleware. The former is equivalent to a Grape formatter, and the latter is equivalent to the Grape endpoint Rack middleware. You have to override the invoke method and implement your business logic.
How does all this come together?
# poncho get "/users", & UsersListMethod
# grape get "/users" do ... end
Grape could easily support the Poncho syntax with a few lines of code. Internally it creates a Proc from the body of the block.
That said, none of the above is difficult to accomplish.
I would certainly have preferred if Stripe chose Grape as the API DSL and implemented their style of data presenters if they felt strongly about that. But we all want our own micro frameworks, don’t we?