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. https://github.com/comster/house
Rethinking web API development
21–27 of 27 posts
Re: Rethinking web API development
#22Why 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?)
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.
Re: Rethinking web API development
#23Matt, now I'm working only with API and I couldn't agree more with you. 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. 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.
Why? HTML is just another output format for a resource. Like Json or Xml.
@MatthewPhillips,
In the real world the HTML output is not like JSON or XML as you told.
It is used to show data to a human and most of the time it contains a lot of elements that are not related with the resource data even if it is not representing more than a resource in the same page.
The interaction with a human doesn't happen in the same way as with another system.
Re: Rethinking web API development
#24Why 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. 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…
My issue with webmachine is the fact that it forces you into HTTP/REST which might not be a bad thing, but I don't like the lack of flexibility and being stuck in a rigid mold. Besides that, webmachine is great.
I think I understand what you're saying, the Webmachine documentation is pretty heavy on the REST. That said, in my opinion it could serve any kind of resource, the library itself doesn't force you to build a RESTful interface.
Re: Rethinking web API development
#25The DSL you describe is remarkably similar to WSDL (http://en.wikipedia.org/wiki/Wsdl) in terms of describing a web service and how to communicate with it.
Granted, DSL is a lot easier to read, since it is using Ruby syntax instead of XML. Functionally, they are the same.
Re: Rethinking web API development
#26Sorry but can someone enlighten me, on why this might be be better than using:
https://github.com/josevalim/active_model_serializers,
Re: Rethinking web API development
#27Earlier quoted context omitted.
Also, if you follow REST closely your APIs should be self documenting.
I have yet to see a REST interface that self describes in details its incoming params and output. REST gives you discoverability which is different from documentation.
Plus, it's actually really HATEOS that gives you discoverability, not just any old REST.
But either way, I agree with you, while the theory is that if you do it 'right' one way or another it's self-documenting, I have yet to see an API which doesn't need good documentation to be usable.
Well, actually, that's a lie, I've seen at least one: The TinyURL "api". Which is obviously extremely simple.