Should we have something about HTTP API/server side routes? about guide HOT 8 CLOSED

You mean like RESTful routes?

The problem is the story here isn't great. You can't even set a 404 😠

from guide.

You can in a regular RESTful route! You just can't set a 404 inside a server-side iron router route that returns the Meteor boilerplate.

But I don't think the story being bad should preclude us from adding it, right? I mean restivus is pretty good, and picker and json-routes are fine lower-level solutions.

from guide.

Oh, right good point. So the story is not great for SS routes that render client side stuff, but it's OK for "pure" SS routes for things like APIs.

I'm not sure where it should go. I don't know about a whole article on APIs. Maybe routing, or we could mention it in the methods article (although there's a lot in there already).

from guide.

We could add an article about integrating with other systems - like we could put the native DDP libraries in there, REST APIs, communicating through the database, etc.

from guide.

That could work.

On Wed, 21 Oct 2015 at 11:06 Sashko Stubailo [email protected]
wrote:

We could add an article about integrating with other systems - like we
could put the native DDP libraries in there, REST APIs, communicating
through the database, etc.

—
Reply to this email directly or view it on GitHub
#49 (comment).

from guide.

But it does have the potential of increasing our workload by 6.67%. Is it worth it? I'm not really sure how to find out.

from guide.

@stubailo we have recently been looking at this issue and we a have come up with a pretty nice solution that were calling CRUD, once the project has been cleaned up and documented ill come here and link you.

The main problem that we think we have solved is how to reuse one cursor for HTTP/Methods and Subscriptions.

Example: CRUD.bind('accounts', CRUD.TYPE_READ, {}, function() { return Accounts.find(); })

This READ method is routed to a publication, method and and HTTP GET endpoint called /rpc/accounts.

A CRUD.TYPE_CREATE | CRUD.TYPE_UPDATE | CRUD.TYPE_DELETE are only bound to methods and http endpoints.

The HTTP interface merges the query params and body data into a single options so that the handler function can do it's job regardless of the origin of the request.

Now we have REST functionality with Meteor socket based transports but only writing the procedure once.

If this is something that catches your interest and you want to get an early look at the work just email me or something.

Cheers.

from guide.

+1 for a full article on API / SS HTTP.

There are a lot of places where This would be tremendously useful,. while reactivity / websockets are amazing, I don't think throwing the baby out with bathwater is ever a good idea. In even a moderately sized application a few restful resources can be very useful, and I believe something that should be covered clearly and concisely in the meteor guide.

from guide.