I'm confused as to why these frameworks don't use the full delete identifier and instead opt for del. delete is a completely valid property identifier for objects and can be accessed identically to del and is significantly less confusing.
If you are using full verbs for everything else, stay consistent please :-/
In terms of a RESTful web service, is an object's id supposed to be passed in as a parameter in a GET request, or be a part of the core URI, e.g. api.test.com/teacher/1234 would retrieve the teacher of id=1234 or api.test.com/students/1234 would retrieve that teacher's students.
I was just reading up on the Graph API Facebook uses and its pattern is just api.test.com/1234/students. There seems to be very little standardization. The tutorial I'm reading right now wants me to pass the id in as a parameter. Weird.
Facebook's REST APIs seem pretty casually designed. "api.test.com/students/1234" is better URL design than "api.test.com/1234/students". You could then naturally guess to use "api.test.com/students" to get a list of students whereas with "api.test.com/1234/students" you'd end up having to do something weird like "api.test.com/all/students".
The thing about all of these Sinatra-like frameworks is there is a lot of code repetition. Instead of passing in a function for each http method for a given uri, it would be nice if I could pass in an object for the uri once, then have the framework call the object's head, get, put, etc. functions.
You can already accomplish this in Express by creating middleware and abstract routes for CRUD stuff.
app.all('/users', middleware, routes.user);
If you're just doing CRUD on a route, that can be abstracted fairly easily. It can also help better organize your code on a larger project (a la MVC-ish), rather than the Sinatra-like feel.
Too many "beginner" express examples show everything in one big file. With all the route logic, etc all in one place, without any CRUD abstraction. Generally these demos are so small that they don't need any abstraction. It takes 20 minutes to write the whole thing, and it's not meant to do much in production. In a production environment, where you have a bigger app, you'll want to abstract away as much of the boilerplate code as possible. Luckily it's fairly trivial to compose abstract higher order functions in javascript to do just that.
1. Small aesthetic thing - in the menu, there are 2 items named "Server API", which are both hi-liting when either is in context.
2. Your intro might benefit from listing not only why/when to use it but what kind of use cases are better suited - eg. which use case brought you to begin building it?
I keep hoping to see more PATCH support in REST frameworks like this, but it doesn't seem to be getting much traction. Perhaps we need to include it with the CRUD operations... CRUPD?
A restify response is a standard node ServerResponse, which means you can call .write() to write to it without closing it. Works fine with responses of indefinite length.
If you are using full verbs for everything else, stay consistent please :-/