Restify 1.0 for Node.js is officially out | Hacker News Reader

Restify 1.0 for Node.js is officially out

mcavage.github.com

76 pointspotomak26 comments

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 :-/

So even though it's a reserved keyword, it's ok to use as a property name?

Looks interesting. I've used https://github.com/visionmedia/express-resource for similar purposes.

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.

Is api.test.com/teacher?id=1234 more kosher?

The pattern used in Rails would be something like api.test.com/teacher/1234/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".

api.test.com/students/1234 would be correct. A REST URL is supposed to identify a resource (noun) when possible.

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.

Thanks for sharing this tip. Do you by chance know of any tutorials on writing middleware that does this sort of thing?

Congrats!

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?

Looking through the rest!

I've just ported Stick from RingoJS to Node, which does the same thing but lets you write code in a synchronous manner: https://github.com/olegp/stick

i fail at seeing the point in forcing javascript to act synchronously

You end up with less code that's easier to maintain, in my experience. Check out this presentation I gave on the topic: http://www.slideshare.net/olegp/server-side-javascript-going...

thx, i'll have a look

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?

Another project with similar aims:

https://github.com/marak/webservice.js

I have been looking for something like this, but I still miss support for building a streaming API. Expected in version 1.1? :)

are you saying restify doesn't allow piping?

Not sure what you mean with piping, but all examples in the documentation are fixed length responses.

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.

http://nodejs.org/docs/lates/api/http.html#http.ServerRespon...

It is not possible to scroll on the documentation from an iphone :(

works for me (iOS 5)

Yeah, scroll is very odd behaving on Android 2.3.

Will this work as a drop-in replacement for express?

Reply on news.ycombinator.com