Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

Add option for creating application without static content [Feature Request] #49

Closed
thebarndog opened this issue Nov 24, 2016 · 1 comment · Fixed by feathersjs-ecosystem/generator-feathers#159

Comments

@thebarndog
Copy link
Member

thebarndog commented Nov 24, 2016

Currently in feathers-cli (which is so awesome thank you all so much), when you generate a application, the default behavior is to serve static content in three places: /, /favicon.ico, and any 404 requests. If someone is building a purely backend application to support a mobile app for example, then returning HTML is less ideal than json responses. It'd be great if there was an option to generate a feathers application that serves 404 responses as a JSON payload with an error message as well as an / response that has authentication turned on by default. I suppose in a typical REST backend application, the / wouldn't return anything but it could (just a thought), render any documentation embedded inside the application or be further configure to support pointing to a separate documentation server.

Do you guys have any thoughts on this? I'd mark it as super low priority because it's really easy to rip out the static content if need be.

@daffl
Copy link
Member

daffl commented Jan 11, 2017

Going forward we'll definitely promote a more API centric approach. I still think it makes sense to add some static hosting though in case someone hits your API in the browser - also accounting for error responses. If the content type is set properly to application/json it will format the error as JSON already. HTML errors can be turned off with app.use(errorHandler({ html: false }).

I've always wondered about registering a root service that returns some basic information but it's on the other hand also risky because an attackers can introspect the API.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants