node-restify
node-restify copied to clipboard
restify
serveStatic is non-intuitive
KISS: Keep it simple stupid. Please make it this for static files plugins, all people have the same problem, in my ofice 5 persons give me the same as bug!!
if you assign this:
server.get(/\/docs\/public\/?.*/, restify.serveStatic({
directory: './public'
}));
will mean that if you get the url "domain.com/docs/public" this will be load the content of "public" folder. END. Not at prefix for the entire route path... and your fairy tales... Kiss men, kiss...
+1
Had to rehack static.js for one application because of this, but would really like to see official solution. I'd suggest to make it as codersbrothers said, or even:
if(typeof opts.directory === 'function') { file = opts.directory(req.path()); }
It's not even important what you do - if it's ok; but please do something
I saw that not its the last version, that 2.6.2 have: #496 static plugin incorrectly handling directories; revert back to 2.6.0 version
This also add something KISS?
You should never use the asterisk, that is an antipattern!
npm install restify --save will save with correct versioning, please use this, not the asterisk
That's great news @gergelyke, I think the behaviour @CodersBrothers describes follows the principle of least surprise.
@gergelyke what is the new version you mentioned? I can't seem the find a fix-related commit recently.
Can you please re-open this issue? It still isn't fixed, the directory property is still being used as a prefix for the full file-path. I would expect that the directory property defines the dir from where the requested filename (not the filepath) is served.
Yes, I agree, the directory property is not intuitive at all - can this be fixed asap please.
Yet still the same? LOL! Yet its so hard enable static files? You are joking?
This not was resolved @gergelyke... all people are saying you... why you don't hear?
I think restify should not bother with serving static files - it is not its responsibility @mcavage how about removing it in the next major?
I think the same, restify will be for REST. But if you decide that can serve static, please make this KISS
+1 If you have any sort of complex URL scheme (like path based routing), being able to filter out a prefix is really nice.
I think restify should not bother with serving static files
Why? It's not a big addition and it allows restify to also serve a HTML5 client. All my apps do this.
Anyway, nice little hack for virtual subdirectories:
Another vote for fixing or removing this feature, or at least calling out the behavior more clearly in the docs.
As long as it's possible to do this with connect middleware or something, and documented. I think this is a big use case but I agree that wether it's in the scope of restify or not if questionable.
Because of CORS letting a REST API also serve a client is useful. Having it as minimal as here is useful. Coding a function to serve static file by yourself is easy though.
The existing implementation of serveStatic is broken and the example straight out of docs does not work. I have wasted a couple of days due to that, and now switched to using module serve-static.
I agree with most on this thread. Serving static files isn't part of Restify's core competencies. Rather than continue to include a broken static file serving implementation, the existing plugin should be removed, in favor of pointing users to documentation on how to perform the same function.
I'm in favor of spinning the existing plugin out to it's own module and allowing people to include it if they'd like.
GETting static files is the epitome of REST! HTML is a media type that uses HATEOAS, so it is the original (true) REST API format.
I would love to see restify support this in an easy to use and intuitive way.
In case someone have this issue, This worked for me :/
server.get(/\/?.(js|css|png|jpg)/, restify.plugins.serveStatic({
directory: './public',
default: '/index.html'
}));
server.get(/\/?.*/, restify.plugins.serveStatic({
directory: './public',
file: '/index.html'
}));