Most of the things you describe have nothing to do with REST. That might be part of your problem :)
228 karma · joined August 12, 2009
{web,mad,computer} scientist; {tech,scifi} writer; home{brew,roast}er; mozillian
Following the REST patterns means you can take advantage of things like standard agnostic intermediaries for caching & filtering. You can switch or even spread across service providers by changing domain names in URLs. You can mitigate network issues through guaranteed idempotence and using conditional headers like if-none-match. These are all issues that you'll probably have to rediscover and re-solve on your own, if your API lives long enough.
It is not about SEO or visually "clean" URLs. REST says nothing about that, despite many misconceptions otherwise. In fact, in a truely RESTful service, resource URLs can be obscure garbage like http://example.com/A13D-DE45-32BC. If you're using the HATEOS principle, those URLs will be picked up from links in your responses.
"Pidgeonholing" your errors to standard HTTP error codes means that you've followed a shared standard, rather than inventing your own from scratch. Also, 4xx errors generally refer to something in the client's request, while 5xx errors generally mean something has gone wrong while generating a response on the server side.
If you don't need any of these things - because, say, you're building an API that will only be used between two parts of your own small system - then don't worry about REST. Go ahead and build something along RPC lines.
You might regret it someday, if you find yourself needing the scaling characteristics of the WWW. But, many systems never grow to that point anyway.
That's called research. You do it on your own time, while using more mature & proven solutions for daily work. Play with it, review all the source code. Like it or not, it's going to be your code, once you start using it in earnest. Don't treat it like a friendly black box.
Is that too much to do? Then you're going to have a lot of surprises. Maybe that's fun for you, but I have to say it gets really old over the years.
> It requires a certain amount of cognitive dissonance to point to Etsy's 2000 files as a failure while at the same time they are a successful company.
Er, no, it doesn't require cognitive dissonance at all. In fact, the folks at Etsy blogged about the issues themselves.
It's a common thing for a fast moving, highly successful project to accumulate gunk under the excuse of "it works for now, we'll clean it up later". But, if the clean up never comes, that gunk eventually becomes a noticeable drag on daily development.
> And it's not a particularly interesting one, imho. I'm not sure why so much ink is spilled on it other than it's easy to form opinions around.
If it's not particularly interesting, then why are you reading about it and responding to it? :)
There will never be access to run native binaries on a Firefox OS device. Web APIs are as close to bare metal that it will ever expose.
Seeing that as "totally lacking any sort of real native software development support" misses the whole purpose of the OS, because the web is native on Firefox OS.
This is way over-simplifying it, but: MindTouch looks like a fork of MediaWiki (PHP) that's had all the database calls replaced by requests to a local web service running on .NET, with a Lua-based document scripting system (DekiScript) added on.
However, MDN ran all this on Linux servers - rather than Windows servers - so our installation was rather unusual. Eventually, the company behind the software decided to drop support for our kind of setup. So, we decided to move over to software we could support in-house, and launched it around June 2012.
What we have now started from the Django-based wiki that runs support.mozilla.org, called kitsune. From there, we worked on getting some practical feature parity with MindTouch. I added a node.js-based document scripting service (KumaScript) that mostly replaced DekiScript for our needs. We worked up some migration scripts, and moved the whole thing over.
It's admittedly kind of an evolutionary mess, at this point. But, at least it's our mess.
The thing is, though, how do you use bookmarks? I hoard everything and rely on search. I feel like once you're over a dozen or so, that's what you need to do. I long, long ago gave up trying to organize them by hand
I use my pinboard to collect links from my tweets and status updates posts, and I use IFTTT and a to:fb tag to post from pinboard to facebook.
I also use a bookmarklet to post to pinboard with tags.
Later, I use pinboard as a personal search engine between tags and search terms. Basically, everything I used to do with Delicious for years
We're rewriting the wiki basically from scratch [1]. There are problems and growing pains. Pull requests welcome!
In short: We're in the process of basically rewriting the wiki software from scratch, right now [1]. There are a lot of growing pains. MediaWiki won't cut it.
Pull requests welcome!
The HTML5 authors & editors have already spent years reverse engineering and describing the behavior of existing browsers as part of that spec.
I'm sure everyone was overjoyed at the prospect of starting the same process for every quirk and bug of that specific version of SQLite, and bumping the spec every time the project released a new version. Or, alternately, living with a fork of that specific version of SQLite forever.
Seriously, that's an awesome way to write and maintain a spec. How about you do the web a solid and give it a shot? Come back when you've got something.