Comment puis-je utiliser un service JSON comme modèle pour une application Rails 3.2?
Je voudrais lier des méthodes de modèle aux demandes JSON, par exemple
myModel.create pour générer une demande JSON pour créer un nouvel enregistrement
-
myModel.find Pour générer une demande JSON pour récupérer un enregistrement et décoder la réponse JSON dans un objet de modèle
Quel est le moyen préféré de construire ce type de fonctionnalité? Une option que je regarde consiste à créer une personnalisation adaptateur Datamapper .
Merci.
mise à jour:
Notez que je ne peux pas utiliser Activeresource, car cela nécessite que le service JSON réponde d'une certaine manière, ce qu'il ne le fait pas dans ce cas.
5 Réponses :
Je fais juste ceci dans mon joyau " OTRS_Connector " ... Cela ne fonctionnera pas pour votre Service, mais cela peut vous donner une idée sur la façon de le faire ... L'approche que j'ai prise n'est peut-être pas la meilleure et doit être refactore un peu, mais cela fonctionne et bien bien à cela.
Merci, je vais regarder cela.
Je pense que ce que vous recherchez est activeresource , vous pouvez l'utiliser à la place de activeCord pour travailler avec une API JSON reposante voir Ce lien et ceci (apidock)
Merci. Malheureusement, cela semble exiger que l'API JSON réponde d'une certaine manière que celle avec laquelle je travaille ne fonctionne pas. Par exemple, il répond avec OK si un nouvel enregistrement est créé, plutôt qu'une représentation JSON du nouvel enregistrement.
La meilleure façon de le faire est de mettre en œuvre un actif. Ce railscast couvre les bases.
Merci, je vais regarder ça. Quel est l'avantage d'Activemodel sur Datamapper?
ActiveModel est inclus dans les rails, vous en bénéficiez donc d'une meilleure prise en charge de la boîte.
Réponse courte: Cela dépend de votre service JSON.
Le service est-il reposant, pour commencer? Si oui, vous avez de la chance. Activeresource est Dead , donc je ne conseillerais pas l'utiliser, mais le code lui-même fournirait Un bon point de départ pour la création d'un ensemble de méthodes d'emballage tels que Cet article résume bien: < / p>
Rails est extrêmement facile de créer des services Web qui suivent les principes de repos et fonctionnent également bien avec les navigateurs Web et le Web programmable. En fait, beaucoup de cette simplicité vient directement de suivre ces principes. Nous n'avions pas à dire à notre client comment créer, lire, mettre à jour ou supprimer la ressource, ceux qui ont tous suivi de l'utilisation des méthodes HTTP appropriées. Tout ce que nous avons dû faire est de pointer notre client au bon endroit.
Si votre service est pas reposant, qui jugeait des commentaires sur d'autres questions, je pense que c'est peut-être le cas, alors vous aurez votre travail découpé pour vous. Activemodel ne fera pas ce travail pour vous: Quelle offre ActiveModel est toutes les autres choses qui font des rails si utiles pour traiter avec des modèles: son système de validation, méthodes de sérialisation, suivi sale des modifications d'attribut,
Callbacks ( Voici donc ce que je recommanderais, basé sur mon expérience bien limitée (voir ma note finale à ce sujet):
Cela vous fera grandir une grande partie de l'utilisation de votre service JSON en tant que modèle Rails.
Pour le compte rendu, mon expérience en réalité en train de mettre en œuvre ce genre de chose est limitée à la construction d'un wrapper API (dans les travaux) pour accéder à une API XML. Le wrapper a une classe comprenant des validateurs Activemodel pour la validation des requêtes de l'API. J'ai trouvé les validateurs Activemodel vraiment utiles pour garantir que l'API est accessible correctement, mais le wrapper est uniquement destiné à obtenir des enregistrements de l'API, et non pour la création ou la mise à jour, de sorte que l'interface est donc beaucoup plus facile que ce que j'attends. Vous serez immobilisé. Créer et pour accéder à votre API et manipuler des enregistrements comme Activerecord crée et interroge des enregistrements dans la DB. C'est relativement facile si votre API est reposante car Rails est construit autour de reposer-ness < / a>, donc la cartographie entre les deux devient beaucoup plus propre.
créer est défini dans activeCord :: persistance et trouver est défini dans activeRecord :: FrederMethods .
Ils ne sont pas dans ActiveModel. ActiveSource est capable de les reproduire assez facilement, car il fait des hypothèses sur le type de service qui est interface avec (c'est-à-dire qu'il est reposant, plus quelques autres choses).
avant_save , après_save , etc.), la traduction / la localisation, etc. Ce sont toutes des fonctions très utiles pour avoir, mais elles vous laissent toujours avec le problème de l'enveloppement de vos appels d'API.
Créer , Trouver et quelle que soit l'autre fonctionnalité de type ACTiverecord que vous souhaitez avoir. Vous voudrez probablement utiliser une gemme comme
faraday ou httparty pour effectuer des demandes à l'API plutôt que de travailler directement avec Net :: http. (Je n'ai jamais utilisé Datamapper alors ne peut pas commenter à ce sujet.)
Merci pour une réponse aussi complète. Heureusement, le service JSON est reposant, c'est juste qu'il ne répond pas à la manière prévue par Activeresource. Je vais éviter Activeresource maintenant que je sais que c'est mort et lira plutôt l'article Dzone que vous avez lié à. Merci encore!
Oh c'est de bonnes nouvelles! Dans ce cas, la tâche ne devrait pas être trop difficile. Même si vous n'utilisez pas ActiveResource, vous pouvez essayer de consulter le code pour voir comment cela fonctionne.
Au cas où vous travaillez toujours sur cela, quelques autres pierres précieuses qui pourraient être utiles: Github.com/filtersquad/api_smith Github.com/Remiprev/her
Si le service Web est en dehors des "rails" normaux de faire des choses, je recommanderais httparty a >. Il est assez facile de faire un proxy sur le site Web qui répond cependant que vous le souhaitez.
Par exemple, voici leur exemple d'accès à la chronologie Twitter P>
class Twitter
include HTTParty
base_uri 'twitter.com'
def initialize(u, p)
@auth = {:username => u, :password => p}
end
# which can be :friends, :user or :public
# options[:query] can be things like since, since_id, count, etc.
def timeline(which=:friends, options={})
options.merge!({:basic_auth => @auth})
self.class.get("/statuses/#{which}_timeline.json", options)
end
def post(text)
options = { :query => {:status => text}, :basic_auth => @auth }
self.class.post('/statuses/update.json', options)
end
end
twitter = Twitter.new(config['email'], config['password'])
pp twitter.timeline
Merci, c'est une alternative intéressante, mais je préférerais que le service JSON fonctionne comme un modèle traditionnel de rails.