Ist es erforderlich, einen separaten API-Endpunkt für mobile Apps zu erstellen, um auf eine Rails-Webanwendung zuzugreifen?

Question

Ich habe eine Web-Anwendung in Ruby on Rails 4 implementiert, brauche eine native App für Android, ich bin wirklich neu in der mobilen Entwicklung.

Ich bin ein wenig verwirrt, wie die Mobile-Web-Architektur in diesem Fall aussehen sollte. Ich habe online recherchiert, es scheint ein paar Wege zu geben, dies zu tun, aber ich habe immer noch einige Fragen, auf die ich keine Antworten finden konnte. Vielen Dank im Voraus für alle Hinweise.

1) Benötige ich wirklich eine separate API für die mobile App? Was sind die Probleme bei der Verwendung der vorhandenen Controller meiner Rails-App mit respond_toformat.json?

2) Ich habe einige Online-Beispiele gesehen, die vorschlagen, einen separaten API-Namespace in der Rails-App zu verwenden, um mobile Anfragen zu bedienen, zum Beispiel class Api::ApiController < ActionController::Base für den neuen Controller, dann fügen Sie namespace :api do in routes.rb hinzu. Bedeutet dies nicht, dass ich in diesem neuen Namespace ein paar meiner Controller-Funktionen nur für Mobilgeräte duplizieren muss?

3) In Bezug auf die Authentifizierung, schlagen viele Beispiele Token-Authentifizierung verwenden, ist die eingebaute in Rails Sitzungen Management-Framework nicht gut genug für mobile Anwendungen? Oder liegt es daran, dass Session-Cookies in einer mobilen App völlig anders funktionieren?

Schätzen Sie Ihre Zeit.

Answer 1

Es ist nicht notwendig, aber es ist, wie Sie sagten, eine Best Practice.

1 + 2) Es ist eine gute Idee auf den ersten Blick, die gleichen Controller mit reply_to/respond_with logic zu haben. Aber aus meiner Erfahrung kann ich sagen, dass es immer einen Tag gibt, an dem sich der API-Code mit dem HTML-Client-Code unterscheidet. Der mobile Client hat möglicherweise eine andere Benutzeroberfläche und es ist nur natürlich, dass er Ihre Daten auf eine andere Weise konsumiert als Ihr Webclient. Der Webclient ist auf einen Anwendungsfall spezialisiert, in dem eine API generischer sein sollte, was mehrere konsumierende Arten erlaubt.

Das zweite Problem, das auftreten wird, ist die Tatsache, dass Sie sich nicht darauf verlassen können, dass Ihre mobilen Benutzer immer die neueste App-Version haben, wo Sie mit einer Webanwendung können. So können Sie für die HTML-App leicht nicht kompatible Änderungen einführen, weil Sie einen richtigen Client innerhalb von wo für die mobile API das Brechen der API zumindest betrifft, liefern. Vielleicht möchten Sie eine Abwärtskompatibilität beibehalten, die Ihre Allzweck-Controller hässlich macht. Und ohne einen richtigen api/v1-Namespace können Sie nicht zwei verschiedene API-Versionen gleichzeitig haben.

Sie können Doppelungen Ihrer Logik vermeiden, indem Sie Ihre Controller sehr dünn halten und die Logik in Modelle verschieben (Serviceobjekte sind auch Modelle, nicht nur Active Records).

3) Ihre mobile HTTP-Bibliothek wird mit hoher Wahrscheinlichkeit eine ordnungsgemäße automatische Cookie-Verwaltung haben. Die tokenbasierte Authentifizierung ist nur eine bewährte Methode. Wenn es nur ein Token vs Session-ID in Cookie ist, wird es nicht viel gewinnen. Ich kann nur denken, dass es automatisch sicher gegen CSRF-Angriffe ist und Sie können diesen Schutz komplett für die API deaktivieren, da Ihre Website-Benutzer die API nicht nutzen dürfen, nur indem sie sich auf der Site anmelden (ein zusätzlicher Vorteil) . Bei der sitzungsbasierten Authentifizierung müssen Sie bei der ersten API-Anfrage ein CSRF-Token generieren und es in den Cookie X-CSRF-Token setzen.

Der große Vorteil der tokenbasierten Authentifizierung besteht darin, dass sie zu mehr Sicherheit erweitert werden kann, wie das Einführen von Ablehntokens, HMAC-Token usw., wobei die Sitzungsauthentifizierung nicht funktioniert. Siehe Using Sessions vs Tokens for API authentication

Ich würde Sie auch ermutigen, zu betrachten json:api. Es kommt von den Entwicklern von ember.js, die darüber nachgedacht haben, Entscheidungen beim Erstellen von APIs zu minimieren. Eine andere interessante Sache ist ein active_model_serializers Juwel. Ein Intro dazu gibt es innerhalb Rails: The Next Five Years by Yehuda Katz