There are many ways to create REST API, I would favour having packages rather than made it into Meteor official release, likewise in Node.js, some adopted HAPI.js, some Express.js, some these and that. I hope this answer your question.
1 Like
Thanks for your answer. I like it and it’s really logical. It would just be nice to have a ‘‘production ready’’ package for this or like I said adding it to core alongside the publications in DDP.
While I certainly think REST APIs are important for any current app server to offer I’m not sure I see the motivation for a core-based implementation of it. It isn’t a cross-cutting concern afaics. In other words, it won’t affect code outside of itself much, and different implementations of it could be swapped in freely as the access is all HTTP standard.
So leave it to packages…yes I know you’re taking a dim view of 3rd party capability but there are some good 3rd parties coding solid packages for Meteor. HTTP APIs aren’t rocket science, and I think there are multiple implementations that do fine already. Note that reactive REST is somewhat of an oxymoron. REST is wrapped around ideas like idempotency that reactivity contradicts.
2 Likes
Just to share, Postman for REST on Google Chrome, cool tool for testing other than CURL.
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
1 Like
I recently started using Restivus for one of my project, and I’m really happy with the results. I’d like to strongly recommend using it, also I’d like to add my support to having it as an official package.
6 Likes
Hey folks. As the creator of Restivus, I feel somewhat obligated to respond here. I think @spicemix pretty much has it on the money, but I just wanted to show my support.
@orbyt If you ever decide to come back to read this, I think you misunderstood the original post, which has caused a needless argument and some unkind words around what should have been a proactive discussion. skini26 is not saying that Meteor should replace it’s DDP framework with REST. That would be completely absurd, and would absolutely destroy Meteor’s reactivity, which nobody wants. But not everyone everywhere is ready to consume data over DDP, and in fact REST is still a largely popular and widespread technology for non-realtime APIs. If you’re exposing an API publicly, where you don’t have control over every client app consuming your API, chances are you’ll want to have a REST API available, since it is a familiar standard for developers.
skini26 While it would be an honor to someday have something I worked on considered an official package for Meteor, I completely agree with proyb2 and @spicemix that there are plenty of third party solutions in Meteor for tons of other things that are perfectly acceptable solutions. There are plenty of capable developers in the Meteor community, and by taking some of this burden off the core developers, they can work on the difficult problems. Rails is a very mature framework, and a large part of its success is the third party gems. Speaking of Rails, Grape - a third party REST framework - is a widely accepted solution (and my personal favorite from my limited time with Rails). The same goes for Django, another mature web framework. REST Framework is third party, and that is the accepted REST solution, from what i can tell. Those are two of the most popular web frameworks, and they both have widely accepted third-party REST solutions. I don’t think Meteor should or will be any different, for all the reasons @spicemix outlined.
Finally, thank you so much anbuselvan for lending Restivus that huge compliment! That made my day!
14 Likes
Thank you for your answer, you understood exactly what I meant.
You are a competent developer and your package is awesome, I hope that you will have a lot of support and contributors to make it the de-facto Rest API smart package and production ready to handle thousands of requests and be scalable . I’m not competent enough to help you but I wish I was.
Talking about performance and scalability, do you have some benchmarks to compare it to other node frameworks and also to Meteor methods and non-reactive publications ?
If you can prove to people that Meteor can be used as a complete and legit Rest API with the same performance as others, people will have no reasons to use express or any other framework. They will try Meteor and then they will discover DDP and progressively switch to it. I think that this is a really good strategy to attract a lot of people to Meteor.
Thank you !
3 Likes
Not to favor one for the other, but DDP can be, and is being, used outside of meteor. It has a really great specification and some very good implementations.
There are applications out there (java, .net, javascript, ios, etc) that use DDP to connect to meteor apps.
Here is a comprehensive list: http://www.meteorpedia.com/read/DDP_Clients
And here is one that’s the latest ‘hype’: http://mondora.github.io/asteroid/
It is nice to have two different options, and it is even nicer that there are multiple options for each of them and that they are community contributions.
1 Like
Hi @orbyt, Alice here from the Meteor team.
I deleted your most recent post in this thread; we want the Meteor forums to be a civil and delightful place for community conversation to happen, and this means we cannot tolerate mean-spiritedness or name-calling here. Your post was flagged as inappropriate by 7 people, and continuing to act against the forum guidelines may cause your account to be banned.
I know people will disagree with each other sometimes, but let’s all work to treat each other kindly even when we disagree. I trust that, going forward, you will help us keep the Meteor community friendly, and I hope to see you posting lots!
6 Likes
I too was looking for REST api with meteor. But that was sometime back.
After spending some time with Meteor, it got me thinking - if client is using REST, then is Meteor the right server?
The question I have is: why should one go with Meteor for REST and not go with its parent, NodeJS.
Would Meteor be able to handle serving simultaneous REST connections as efficiently as a base NodeJS server could do?
Accessing collections over REST, that’s a different story though. Meteor may shine there with collections REST api - but then one can always go with MongoDB REST api !!
Hope some one can clarify from “core architectural stand point” if meteor is indeed capable of REST (contrasted against other servers in terms of connection handling and throughput)
4 Likes
Hi guys!
@rgoomar linked me to this thread, seems pretty intense.
@skini26 @anbuselvan @kahmali I agree with you that Restivus is pretty awesome, I also like cfs:http-methods. It seems to have a lot of functionality and options that people would be looking for in an official REST implementation. I think it would be great to somehow promote these packages as a community solution to this commonly requested feature, until Meteor has it built in.
@spicemix I see your point about REST support not necessarily needing to be in core, but I think there are actually some ways that it could be integrated well into the framework. Some examples are having an official solution for HTTP-based authentication, automatically having an HTTP equivalent for your DDP based APIs, etc. Also, there’s a marketing concern - people might feel that Meteor doesn’t really “support” REST if it’s not part of core.
@KrishnaPG @skini26 Regarding Meteor’s performance as a REST API backend, I can’t think of anything that would make it slower than any other Node app when handling HTTP requests. Meteor has many features beyond just DDP, and it would be great for people to use it even if all they need is a REST API for their mobile app. As you said, there are a lot of benefits - Meteor has great built-in functionality for handling collections, easy deployment, fast development with server reloading/hot code push/meteor shell/meteor debug, etc. Plus, if you decide that you want a webapp or PhoneGap/Cordova app to go alongside your native mobile app, you can easily build a DDP frontend to the same data.
In conclusion:
I don’t think DDP and HTTP need to be enemies. There are a lot of cases where DDP is the right solution, and some where you need HTTP. It would be great if this wasn’t even a point of discussion for people when deciding whether to try out Meteor - it should be just as good or better to build your REST backend with Meteor as with Express or Rails, then everyone wins because you don’t need to choose your server by first deciding on DDP vs. HTTP.
Shameless self-promotion:
I’m currently working on a package for Meteor that will make it ultra-easy to have the exact same API for your app over DDP and HTTP: https://meteor.hackpad.com/Meteor-Hack-Week-REST-APIs-with-Meteor-XK2NNXqhUvj
That way, you can just write your app using the normal Meteor stuff like publish, methods, allow/deny, etc. and then consume it over whatever protocol you like.
14 Likes
Awesome! Thanks @sashko for the detailed response. I totally agree with you on the idea about community promoted packages, as still developers are struggling to pick the right package from atmosphere to complete certain task, because it’s just showing whole list of packages, and I’d like to strongly suggest at least all the packages should be tagged to certain categories (an email to the package owner to tag their packages to right category/tag would be sufficient?), so that it’ll be easy to select a right package to complete a task (or entire meteor project) quickly and efficiently.
Here’s a sample flow:
- launch atmosphere.
- Select Category or Tag.
- See the list of packages order by recommended, trending, most installed, etc., in that particular category.
- Pick the recommended packages.
Regarding REST APIs, I have this conversation when I make decision every time like to deploy a Meteor backend to serve the APIs for native mobile clients, and I always convinced to use Meteor for the main website (only!), and Restivus for native mobile clients.
There are few client libraries already available to support DDP natively as well.
e.g:
Can’t wait to try your REST package (HTTP and DDP) once it ready!!
Thanks @sashko From the technical / architectural standpoint, I am looking for pointers on how REST gets impacted due to the differences between the Meteor and Natural Node.js:
For example,
- lets take away all client side advantages (such as latency compensations etc. which make it feel like meteor is more responsive)
- lets take away reactivity (and reactive collections, ddp so on…)
- and let us assume client is using pure request-response HTTP/REST operations,
in such situation what kind of performance benefits (throughput, simultaneous user count …) meteor architecture has over bare node.js.
For example, lets say 10K sensor devices from all over the world are using HTTP PUT to insert some data into server constantly.
In such scenario, what are the advantages one can expect from Meteor architecture? For example, Fibers (vs nodejs single threaded model), - how would it affect, and any other differences that contribute to:
- No. of simultaneous connections that are possible
- Response time of each connection
- Throughput of the amount of data handled
slightly unrelated but … how tied is client side minimongo to HTML5 features? there seem to a number of platforms for doing native apps in JS nowadays (reactnative, nativescript, titanium etc) and it would be great to use meteor as just a data backend for them (to start with). However, having collections and mini mongo client side to manipulate/filter the data is very convenient.
Most of these platforms are not built on the browser tho, just on whatever JS runtime (javascript core / V8) so the whole html5 APIs aren’t available. I was wondering how difficult it would be to take minimongo to one of these pure JS platforms?
The step after that is of course providing DDP but not everything needs to be reactive…
1 Like
@kahmali, I’ve built a super duper simple JSON API package here: https://github.com/stubailo/meteor-rest/tree/master/packages/json-routes
I filed an issue on Restivus to remove the iron:router dep: https://github.com/kahmali/meteor-restivus/issues/38
Let me know if you are interested and have time to work together on integrating these to remove the dependency of Restivus on I:R. It should be minimal work, I just need two things:
- What is the return value that Iron Router expects in server side routes? I can’t find it in the documentation, and would like to replicate it in my package.
- Would you accept a PR replacing I:R with my package in Restivus?
7 Likes
Hello everyone! I’ve spent my week experimenting and trying to push forward the state of REST APIs in Meteor, and I’ve come up with a preview release of a package:
simple:rest - The easiest way to add a REST API to your Meteor app.
Let me know what you think! It’s a preview, I’m open to changing anything that doesn’t seem right.
It’s not meant to solve every aspect of REST APIs for Meteor, just make a simple default that works for a wide variety of cases. I’ve also been working with @kahmali to improve Restivus, and will continue in the future.
10 Likes
This is perfect ! I’m gonna try it thanks ! 
great discussion. I have just been working with restivus and I really like it. I put together a very simple demo to help anyone get started with it (It’s based on the quickstart from restivus, but doesn’t use authentication and is a bit simpler)
as for one comment about why you might use REST as part of a meteor app, here’s a use-case: Say you are writing a meteor app and it needs to process incoming email messages… and you are using mailgun.com which provides hooks where they will POST to your REST endpoint the contents (json formatted) of any incoming mail message to their servers. In this case, without REST support in meteor, one would have to have a separate server running PHP/Apache or something like that which would accept the post from mailgun and insert it into some mongo database that your meteor app was also connected to. Possible, but much more bother than just enabling a REST endpoint in the main meteor app.
6 Likes
Don’t mean to bring up a dead post but I felt it was important to leave an update here since this page is one of the top hits when doing a google search of meteor + rest.
There’s a meteor supported alternative to these dead packages. It’s in the meteor-base package and is called webapp
2 Likes
Here’s a lib that might be helpful to some:
And here’s an example app showing how to use it:
Also, here’s a meteor feature request I put in on this topic, and the feedback:
And here’s another thread on it: