Как открыть веб-службу RESTful с помощью Meteor

Как бы вы хотели создать спокойный веб-сервис с помощью Meteor. Я хотел бы создать приложения в Appcelerator, которые подключаются к одному бэкэнду.

Может ли Метеор решить эту проблему?

Ответ 1

Предположим, вы, вероятно, можете создать RESTful-сервис с помощью Meteor, но это не совсем то, для чего предназначена инфраструктура. Одним из основных преимуществ Meteor является тесное взаимодействие между клиентом и сервером, а веб-сервис не работает, t иметь клиентскую сторону. Я бы порекомендовал заглянуть в конец веб-службы в node.js самостоятельно или что-то вроде https://github.com/intridea/grape, если вам нравится Рубин.

Ответ 2

Я сделал полную запись об этом в Meteorpedia:

http://www.meteorpedia.com/read/REST_API

Сообщение проверяет все 6 вариантов создания интерфейсов REST от самого высокого уровня (например, интеллектуальных пакетов, которые обрабатывают все для вас) до самого низкого уровня (например, для написания собственного connectHandler).

Кроме того, сообщение распространяется при использовании интерфейса REST - это правильная или неправильная работа в Meteor, ссылается на инструменты тестирования Meteor REST и объясняет общие проблемы, такие как проблемы безопасности CORS.

Ответ 3

Первоначально я ответил на этот вопрос здесь, но напомню:

Чтобы добавить методы RESTful поверх ваших данных, просмотрите API-интерфейс Collection, написанный для Meteor:

https://github.com/crazytoad/meteor-collectionapi

Что касается аутентификации для доступа к базе данных, посмотрите на этот проект:

https://github.com/meteor/meteor/wiki/Getting-started-with-Auth

Оба из них, безусловно, инфантильные в разработке, но вы можете создать RESTful API и легко интегрировать его с мобильным родным клиентом.

Ответ 4

Я знаю, что это старый поток, но в случае, если кто-то наткнулся на него, я опубликовал пакет для написания REST API в Meteor 0.9.0 +:

https://github.com/kahmali/meteor-restivus

Он был вдохновлен RestStop2 и построен с Iron Router на стороне сервера. По моему не очень скромному мнению, это лучшее решение, чем что-либо, опубликованное здесь до сих пор.

ОБНОВЛЕНИЕ: Чтобы выяснить, почему я считаю это "лучшим" решением, чем упомянутое, я просто укажу различия между ними:

CollectionAPI:
CollectionAPI ограничивается экспонированием очень простых операций CRUD в ваших коллекциях. Для моего использования, которое потребляет API REST в мобильных приложениях, может быть очень расточительно отправлять все документы, и большую часть времени мне нужно выполнить некоторую дополнительную обработку данных (например, отправка Виртуального сообщения Google в Конечная точка REST для добавления друга, но только если друг успешно добавлен). CollectionAPI дает вам крючок, который выполняется до окончания конечной точки, но из того, что я понимаю, нет ничего непосредственно перед ответом, поэтому у вас нет способа изменить возвращаемые данные. Для аутентификации CollectionAPI позволяет вам определить authToken, который должен быть передан с каждым запросом. Это больше похоже на традиционный ключ api, поскольку он, по-видимому, жестко закодирован в ваше приложение и поэтому будет одинаковым для каждого пользователя.

Restivus, поскольку он не ограничивается автоматизированной работой над коллекциями, дает вам полный контроль над конечными точками. Теперь он предоставляет все функции, включенные в Collection API. Он также поддерживает аутентификацию пользователей и разрешения на роль, поэтому вы можете определить пользователя, делающего запрос (и легко получить доступ к этому пользователю из аутентифицированных конечных точек). Он также предоставляет конечную точку входа и выхода из системы, чтобы помочь в этом. Я приведу пример кода для Restivus в конце.

HTTP.publish:
Из того, что я понимаю, это похоже на CollectionAPI в том, что оно ограничивается раскрытием основных операций CRUD в коллекциях. Это более конкретно связано с публикацией Meteor и позволяет использовать функцию публикации для обработки запросов GET. Я смущен документацией, но у нее может быть или не быть доступной базовая аутентификация. Я не использовал это раньше, но я не большой поклонник API для него, который чувствует себя немного неуклюжим. Когда я буду публиковать более подробно, я попытаюсь вернуться к нему. В той же команде есть еще один пакет под названием HTTP.methods, который не дает вам доступа к функциям публикации, но имеет аналогичный api для Restivus и, в то время, аналогичную функциональность.

Restivus "лучше", потому что он не ограничивает вас использованием ваших функций публикации и, следовательно, позволяет намного более мелкомасштабный контроль над вашими конечными точками. Если вы просто хотите опубликовать свои функции публикации во внешнем API, я бы рекомендовал вам использовать HTTP.publish. Restivus также имеет более простой API и поддерживает метод HTTP PATCH (который, как представляется, не существует, какой-либо другой пакет). Их пакет HTTP.methods очень похож на Restivus, за исключением того, что ему не хватает поддержки PATCH, и хотя он предлагает некоторую базовую аутентификацию, я считаю, что у вас есть возможность сделать все конечные точки аутентифицированными или нет. Restivus позволит вам контролировать это на уровне за одну точку (а не только на маршруте). Разрешения на роль (например, user, admin) на конечных точках также доступны на Restivus, но я ничего не вижу об этом для методов HTTP.methods.

Метеоритный маршрутизатор:
Это устарело в пользу Iron Router, см. Ниже.

Железный маршрутизатор:
Iron Router потрясающий, но он специально не предназначен для создания API REST. Недавно они добавили функции, соответствующие HTTP-методам (GET, POST и т.д.), Но они не поддерживают какую-либо форму аутентификации, и все, к чему у вас есть доступ, - это объекты запроса и ответа более низкого уровня Node, поэтому вы я буду вынужден научиться работать с ними. Как только вы это сделаете, вы обнаружите, что в каждой конечной точке выполняется некоторая повторяющаяся работа, например, создание ответов с соответствующими заголовками и кодами ответов. Вам также придется беспокоиться о соблюдении CORS, если ваш API будет потреблен из браузера.

Restivus фактически построен поверх Iron Router и обеспечивает уровень аутентификации на конечных точках. Он также абстрагирует необходимость прямого взаимодействия с объектами запроса и ответа Node, хотя они все еще существуют, если мы что-то пропустили. Таким образом, он использует всю удивительность Iron Router с API более высокого уровня для вашего удовольствия от кодирования. Restivus отлично, если вы уже используете Iron Router, так как он не добавит никакой дополнительной зависимости.

RestStop2:
Я фактически использовал RestStop2 в проекте, над которым я работаю, когда он устарел в пользу Iron Router. У них была прочная документация, и API, который я предпочитал выше других. По их предложению я построил новый пакет поверх Iron Router, который очень вдохновлен RestStop2. Restivus теперь поддерживается на странице RestStop2 GitHub, поэтому я думаю, что они согласны с тем, что это достойная замена.

Вот небольшой фрагмент кода из раздела быстрого запуска документов Restivus:

if(Meteor.isServer) {
  Meteor.startup(function () {
    // Global configuration
    Restivus.configure({
      useAuth: true,
      prettyJson: true
    });

    // Generates: GET, POST on /api/users and GET, DELETE /api/users/:id for
    // Meteor.users collection
    Restivus.addCollection(Meteor.users, {
      excludedEndpoints: ['deleteAll', 'put'],
      routeOptions: {
        authRequired: true
      },
      endpoints: {
        post: {
          authRequired: false
        },
        delete: {
          roleRequired: 'admin'
        }
      }
    });

    // Maps to: POST /api/articles/:id
    Restivus.addRoute('articles/:id', {authRequired: true}, {
      post: {
        roleRequired: ['author', 'admin'],
        action: function () {
          var article = Articles.findOne(this.urlParams.id);
          if (article) {
            return {status: "success", data: article};
          }
          return {
            statusCode: 400,
            body: {status: "fail", message: "Unable to add article"}
          };
        }
      }
    });
  });
}

Ответ 5

Кто-то споткнулся об этом сейчас (2013+), проверит Meteor Router смарт-пакет, который предоставляет методы для серверной части маршрутизации, полезной при создании интерфейсов RESTful.

Meteor.Router.add('/404', [404, "There nothing here!"]);

Чтобы помочь вам в будущих поисковых запросах, обязательно посмотрите https://atmosphere.meteor.com - хранилище интеллектуальных пакетов. И Meteorite - довольно удобный инструмент командной строки для управления версиями и пакетами.

Ответ 6

Самое элегантное решение выглядит как HTTP.publish. Вместо того, чтобы изобретать новый API, как и другие, он просто добавляет HTTP-протокол к существующему интерфейсу Meteor publish. Это означает, например, что Meteor.allow и Meteor.deny работают автоматически для HTTP, а также для DDP.

Пример:

Если передана коллекция и функция публикации, то HTTP.publish будет монтироваться по следующим URL-адресам и методам:

GET -/api/list - все опубликованные данные
POST -/api/list - вставьте документ в коллекцию
GET -/api/list/: id - найти один опубликованный документ
PUT -/api/list/: id - обновить документ
DELETE -/api/list/: id - удалить документ

myCollection = new Meteor.Collection('list');

// Add access points for `GET`, `POST`, `PUT`, `DELETE`
HTTP.publish(myCollection, function(data) {
  // this.userId, this.query, this.params
  return myCollection.find({});
});

Он еще не полностью выполняет аутентификацию.

Ответ 7

Да, вы можете разоблачить конечные точки REST с помощью Meteor с помощью частного API. Функциональность скоро станет общедоступной, но в то же время см. Могу ли я смонтировать другой обработчик маршрута через ____meteor_bootstrap____.app?.

Ответ 8

Я знаю, что это старая тема, но вместо использования любого внешнего пакета вы можете использовать пакет Meteor WebApp: https://docs.meteor.com/packages/webapp.html.

Надеюсь, что это поможет!

Ответ 9

Я думал, что буду обновлять разговор на 2014 год. Я все еще не нашел идеального способа реализовать сервисы REST в "Метеор" и "Я", надеясь, что кто-то может указать мне в другом направлении для расследования. Ive протестировал 3 проекта, и каждый из них имеет свои недостатки:

meteor-router Я работал с метеоритным маршрутизатором, но на странице github говорится, что это будет только исправление ошибок в будущем и использование Iron Router для всех новых проектов. Я все еще рассматриваю возможность использования этого, поскольку, если он работает для меня как есть, тогда требуется обновление без необходимости аутентификации.

iron-router У меня есть простой пример службы, созданной с использованием Iron Router, но, похоже, он поддерживает службы REST даже меньше, чем метеоритный маршрутизатор, и приводит к сбою сервера, если кто-то помещает недопустимый json для останова конечной точки.

meteor-collectionapi Предоставляет REST api для базовых операций CRUD, но не поддерживает запросы, отличные от id.