The simplest, totally bare-bones way to add an HTTP endpoint to your Meteor app

Hello everyone!

I got tired of messing around with complicated routing packages and the raw Connect API when trying to define simple server-side JSON routes in my app, so I decided to build the simplest HTTP API package I could think of. Check it out:

I noticed there are several REST API packages becoming available on Atmosphere, and they are all based on different things - some on server-side Iron Router, some on raw Connect handlers, etc. Maybe we can make this package the simple, stable, no-frills base that people can build packages on top of?

Let me know what it’s missing!


Cool, looks simple enough!

Should I be worried about these:

(STDERR) connect.multipart() will be removed in connect 3.0
(STDERR) visit for alternatives
(STDERR) connect.limit() will be removed in connect 3.0

An option to prettify the response object would be handy during development.

Regarding the connect errors, it will be a very big deal if Meteor updates it’s connect dependency (the whole framework is sitting on top of it) and I’ll update the package then.

What do you mean by prettifying the response object? Like JsonRoutes._printResponse that prints the headers, status code, and body or something?

Thanks for this Sashko!

Also, it would be great if the community had a simple client/server side router that was robust and capable enough to take the place of Iron Router – with all respect – without all the ‘extras’. Even in Iron Router, on the server side you’re on your own, so to speak.

1 Like

Thanks. It works really nice and has a clear realization! I have just tryed it but and it is great. And if you don’t mind I notice a few points for the package:

  1. Allow to define custom response types. For now I just use response to send image/* data
  2. It seems to have a multipart/encoding issue when sending large data (but probably it is most connect/meteor webapp issue). I mean that response data isn’t chunked properly

I meant EJSON.stringify(json, {indent: true, canonical: true}) instead of EJSON.stringify(json)

1 Like

Great idea! Filed an issue on my repo:

1 Like

@sashko just sent you a pull request. I hope the code meets your style and standards.

By the way, it is also possible to use an optional parameter on the url and if it is there, we can send an html response (instead of json) which can also be colorized as well as indented.

Let me know if you’d like that, or if you find that too much for a simple package.

Interesting, let me think about that while I take a look at your PR.

So I like the direction of your idea, but I’m not sure that this specific approach would actually add a lot for users.

First, you can call JSON endpoints from your browser console, and inspect them there.

Also, there are chrome/firefox extensions that render JSON nicely in the browser, for example

It looks like this:

These two methods seem pretty good to me, is there some use case I’m missing?

I’m not a fan of browser extensions and inspecting json response from
the console feels too confined in terms of space. But both of them
are pure personal preferences.

I see that you’ve merged my PR. I guess it is sufficient for a general
developer taste and any further requirement can be met as you’ve


No problem! Let me know if you have any other ideas.

Just realized I haven’t responded to this post -

If you use the request and response directly, you can do pretty much anything at all. The JsonRoutes.sendResponse function is more of a convenience function for returning a specific kind of response.

Can you tell me more about the large data issue? Is there a reproduction I can use to try to fix the problem?

Just fixed using readableStream piped to response and setting a Content-Legth header. Seems it is specific Chrome issue.
And yes, request and response allow do anything I need. More over the Router could be extended without any troubles - great and clear work, thanks again.
Are you goung to make a Router for client-side to?

Great work @sashko ! From reading the hackpad and the docs it looks like the simple:rest package will handle CRUD type functionality on collections so I just wasn’t sure when you would want to use something like nimble:restivus or this package? Maybe I am missing something?

@sashko great package! I started using it this week to build an API that can be called from across domains. I am running into the following error:
XMLHttpRequest cannot load <url>. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.

This happens for both localhost and when I deploy to a url. Thoughts?