Rethinking web API development
matt.aimonetti.net
Rethinking web API development
1–10 of 27 posts
Re: Rethinking web API development
#2Matt, 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.
Re: Rethinking web API development
#3Matt, 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.
Re: Rethinking web API development
#4Matt, 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 maybe because the logic to generate JSON and HTML is very often quite different and having a tight coupling at this level might result in some serious pains later on.
Re: Rethinking web API development
#5Is 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.
Re: Rethinking web API development
#6Why 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.
Re: Rethinking web API development
#7Earlier quoted context omitted.
Why? HTML is just another output format for a resource. Like Json or Xml.
@MatthewPhillips maybe because the logic to generate JSON and HTML is very often quite different and having a tight coupling at this level might result in some serious pains later on.
How are they tightly coupled? You take the same data and either run it through a Json serializer or a view renderer.
Re: Rethinking web API development
#8Earlier quoted context omitted.
Why? HTML is just another output format for a resource. Like Json or Xml.
@MatthewPhillips maybe because the logic to generate JSON and HTML is very often quite different and having a tight coupling at this level might result in some serious pains later on.
> You take the same data and either run it through a Json serializer or a view renderer.
My experience might be different than yours, but very often my html views quickly end up needed more than 1 resource to render and now I need to fetch data just for the html templates. The same data set isn't needed when returning json or xml and the API end points exposed for data consumption are often quite different. That said, in some cases, I agree that your approach would work.
Re: Rethinking web API development
#9Is 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.
MVC never worked for regular web pages, it needs bindings and direct feedback to make sense, all the purported MVC web framework were basically full of shit. To "do MVC" on the web, you either do it all on the client, or you split the C across server and clients, with M on the server and V on the client. Something like that.
Or you use different meta-patterns, and you stop lying to yourself (and to everybody else). That's fine, regular web interactions work and work well and they have structural advantages. They just can't do MVC in any sensible manner.
Re: Rethinking web API development
#10I 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.
In other words, I need it to work well with implementing an oauth provider functionality.
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.
Hence Id prefer full Rails environment with things like Devise and ActiveAdmin