Rethinking web API development

Why the crack about Webmachine? It seems sensible that you'd want to factor out all of the logic common to every web service so that you wouldn't keep re-writing it for every service you develop.<p>I don't believe that Webmachine forces you into "a specific way of providing your data." It wants you to provide data in a format that both your service and the client are prepared to understand, again, that seams reasonable.

"I also didn’t mention the whole REST/RPC/Hypstermedia debate since I consider it being an implementation detail and a totally orthogonal discussion."<p>with respect to the author this article is well intentioned but it is (in my opinion) fundamentally misguided..<p>The choice of any of those styles will directly and deeply effect how your clients consume (i.e. couple) to your API.. and ultimately how you are able to evolve and maintain your application over time without heavily disrupting code written against your service.<p>Rails is perfectly adequate for exposing resources, rendering representations, and for publishing documentation - producing yet another framework that is entirely focused on API might help but in largely superficial ways. The challenge of good API design is in exposing it to the world so that it evokes the right behaviour from an ecosystem of clients you don't control the code for. The details of how you put the API and documentation together in the backend are inconsequential to this challenge since it is all hidden from clients behind HTTP.

I wonder how would this Weasel_Diesel DSL framework that sort of drives you toward sinatra deal with number one requirement for most APIs --- being secure.<p>In other words, I need it to work well with implementing an oauth provider functionality.<p>Also potentially one needs to come up with a way for an API consumer to be able to generate oauth credentials in a (hopefully) user friendly way.<p>Hence Id prefer full Rails environment with things like Devise and ActiveAdmin

Matt, now I'm working only with API and I couldn't agree more with you.<p>Last year I worked with a very big and monolithic Rails app and all the time I was wondering about move it for services but it wasn't possible.<p>I'm almost convinced that we can write service layers with a very consistent API and use Rails to consume it as a client. The HTML interface should be only another client.

I'm working on an open source platform for restful api app development, running on node.js and mongo. The idea is to handle the backend stuff so you can focus on the frontend of your choice. But on open source, so something like wordpress for apps. I'd love input on the idea. <a href="https://github.com/comster/house" rel="nofollow">https://github.com/comster/house</a>

Is "Documentation" just an implementation detail for what you really need: "Communication"? If I can have a smooth learning curve and a well-understood contract, then I'll have an API that developers enjoy using and integrating into products. Now granted, I don't see how this can be done currently without proper documentation (even if that just means naming the routes well, and providing illustrative examples), but that doesn't mean it's not possible.

Why not build this as a middleware layer? You can mount a sinatra app within Rails (/services for instance), and then write your API in a predefined path structure that the gem will look into (within the rails app path maybe?)<p>You can pretty easily share models and whatnot -- and then you have a nice clean place to define/override your DSL. I would have to do some playing to make sure this is valid, but that might be an approach to think about.

Sorry but can someone enlighten me, on why this might be be better than using: <a href="https://github.com/josevalim/active_model_serializers" rel="nofollow">https://github.com/josevalim/active_model_serializers</a>,<p><a href="https://github.com/nesquena/rabl" rel="nofollow">https://github.com/nesquena/rabl</a>,<p><a href="https://github.com/rails/jbuilder" rel="nofollow">https://github.com/rails/jbuilder</a>

The DSL you describe is remarkably similar to WSDL (<a href="http://en.wikipedia.org/wiki/Wsdl" rel="nofollow">http://en.wikipedia.org/wiki/Wsdl</a>) in terms of describing a web service and how to communicate with it.<p>Granted, DSL is a lot easier to read, since it is using Ruby syntax instead of XML. Functionally, they are the same.

Is MVC really equipped for this new world? When you write a single page app there's really no need for the V server side, so you left with "MC" and its heavy handed conventions or a Sinatra-like method that more directly maps to RESTful resources.

I'm currently using the rails_api gem for an API only app I'm building. It's pretty lean.