webmachine

webmachine, mochiweb etc. come from Erlang. webmachine is one of the earliest libraries I'm aware of that tried to think carefully about HTTP semantics and structured it's work with restful APIs (or web requests in general) according to an actual diagram that you can see here: https://github.com/basho/webmachine/blob/develop/docs/http-h... There's an expanded and re-worked version that builds on this here: https://github.com/for-GET/http-decision-diagram/tree/master... (follow the links to system, request etc. to see the reasoning and references for each step)

I have used webmachine for web services in erlang, which I liked a lot. Not sure it's much maintained anymore. https://github.com/basho/webmachine/wiki Edit: apparently it's still at least somewhat alive... http://lists.therestfulway.com/pipermail/webmachine_lists.th...

I believe at least some of the pain points of "modern REST" mentioned in the article would be eliminated by wider adoption of proper FSM-based REST implementations, e.g. [1] or [2] (the latter is a spec and not a concrete implementation). This way, REST becomes a "template" for an "autonomous agent"'s logic, kinda like our brains are a "templates" for our personalities. Adoption of such "template" helps to establish invariants, which are crucial for large systems. [1] https://github.com/basho/webmachine [2] https://github.com/for-GET/http-decision-diagram/ edit: formatting

Those languages are all very similar except for javascript, and that's been built to look similar to the others. Try something completely different to shake yourself into another level of understanding. I enjoy Erlang/Webmachine. http://learnyousomeerlang.com/ https://github.com/basho/webmachine/wiki Webmachine has a tiny codebase and clean code that you can read completely and understand in a few sittings, gives you trivally simple output and routing, and lacks opinion. Also, the combination of it and Erlang eliminate the harsh separation of RAM and disk that is a fact of life with single threaded, instance-per-request architectures. Nothing you couldn't do in Node.js, but less fragile - and message passing over callbacks any day. Just making my pitch to anyone in the same situation:)

When looking at the concept, it's interesting to me how much the pseudo code looks like a real REST API handler written in a state machine DSL. Decision graph: http://clojure-liberator.github.io/liberator/tutorial/decisi... Actual code: http://clojure-liberator.github.io/liberator/tutorial/all-to... Progenitor = Erlang Webmachine: https://github.com/basho/webmachine/wiki/Overview I'd rather write a working API than this separate spec language. By writing your 'spec' as a state machine, you get REST formality and consistency, plus, well, you now have something that works. OTOH, running an existing API through something that would generate this RAML document could be very interesting as a way to make sure everyone's on the same page in a language neutral way.

Webmachine (https://github.com/basho/webmachine) has a very nice, declarative approach (Erlang). It was ported to node.js, but hasn't been updated in a while, unfortunately. If that sort of thing floats your boat, you should check out Yesod as well (Haskell).

Whelp I guess this needs updating now, https://github.com/basho/webmachine/raw/master/docs/http-hea...

I really adore using Erlang with Webmachine, jQuery Taconite, and erlydtl for web projects. It's usually not a morally safe option for other people's projects (because what are the odds of them finding an Erlang programmer to work on it after I'm gone?), but it's a joy for my own projects. Easy, and as functional as you want to be:) edit to add links: https://github.com/basho/webmachine http://www.malsup.com/jquery/taconite/ https://github.com/evanmiller/erlydtl