2009-08-18 11 views
1

Nous sommes en train de créer une API compatible REST. Le backend est implémenté en PHP et nous voulons que l'interface suive la convention sur la devise de la configuration. Un grand nombre des consommateurs de l'API seront des développeurs Rails, et suite à une stratégie TDD pour la construction de l'API, nous avons envisagé d'utiliser ActiveResource pour implémenter un consommateur tout en adaptant l'API à ces standards.Rails ActiveResource

Cette approche est-elle tombée en disgrâce? Quelles autres options ou conventions pourrions-nous être en mesure d'adhérer afin que nous puissions nous sentir à l'aise d'avoir construit une API forte (comme Flickr, Facebook, Twitter, etc.)?

Merci pour les pointeurs.

Tchad

Répondre

2

ActiveResource nécessite le XML pour être assez bavard, et l'OMI pas très bien conçu (imbrication des entités peut être un véritable casse-tête)

Si la grande majorité de vos consommateurs seront les développeurs Rails puis en utilisant peut-être REST compatible ActiveResource les services pourraient être la voie à suivre, mais ils auront l'air assez moche pour les consommateurs non-Rails.

Si vous voulez qu'une technologie soit capable de la consommer, je n'utiliserais pas ActiveResource, et je créerais du XML (ou du JSON) qui conviendrait aux données.

J'ai construit quelques systèmes qui communiquent en utilisant ActiveResource, et plus récemment, j'ai trouvé plus facile à faire comme je le suggère ci-dessus.

+0

Merci Dan ... c'est une bonne info et assez proche de ce que nous avions en tête. – Chad

1

en utilisant les conventions de ActiveResource pour cartographier les méthodes HTTP et urls aux actions de l'API est une bonne idée, surtout si comme vous le dites bon nombre de vos utilisateurs utiliseront Rails. En plus de cela, je vous conseille de lire "Your Web Service Might Not Be RESTful If…" comme juste la manipulation correcte GET/POST/PUT/DELETE n'est pas tout ce qui est nécessaire pour être vraiment REST. BTW, la plupart des apis que vous avez mentionnés ne sont pas vraiment REST.

+0

Merci Vitaly. Gotcha sur les autres API - comme d'habitude le but est toujours de modéliser ceux qui ont bien réussi! – Chad

Questions connexes