Musze napisac szybko api typu twitter. Zrobilem maly research i znalazlem dwa gemy do tego
Mial ktos do czynienia z nimi i pomoze mi wybrac lepszy ?
ja zacząłem własnie pisać API i wybrałem acts_as_api. Wydał mi się dużo prostszy od grape i ma wbudowaną obsługę MongoId. Jak narazie nie sprawia problemów 
+1 dla acts_as_api, sama przyjemność.
Nie widziałem wcześniej acts_as_api, ale nie podoba mi się, imho takie rzeczy nie należą do modelu (przy czym sam nie jestem bez grzechu, we wszystkich poprzednich aplikacjach robiłem to w podobny sposób). Grape wygląda lepiej, ale wydaje mi się, że ilość kodu, którą się zaoszczędza nie jest warta stosowania dodatkowego pluginu.
Zgadzam się z drogusem, że wygląd json’a albo xml’a nie jest zadaniem modelu. To raczej zadanie decoratoa (jbuilder) albo widoku (rabl). Projektując API możesz być pewienm, że za jakiś czas będziesz chciał je zmienić. I jeśli twoje API stanie się popularne, to będziesz musiał pomyśleć o jego wersjonowaniu. Warto więc zadbać o to zanim stanie się popularne.
Jakbym miał teraz implementować API to zrobiłym to w ten sposób:
- wersje API odpowiadaja namespace’om w w ktorych są kontrolery z resourcami (dzięki temu nawet jak po refaktoryzacji jakiś model zniknie, to będziesz w stanie utrzymać działanie starej wersji API)
- wersje API i format są określane postawie nagłówka ‘Accept’ (url nie jest miejscem na content negotiating)
- specyfikacja tego jak reprezentacja XML albo JSON wyglada jest w widoku (rabl nie jest doskonały ale imho to najlepsze rozwiązanie na teraz)
Jeśli nie chcesz zbyt szybko robić v2 swojego API wcześniej posłuchaj tego podcastu:
http://rubyrogues.com/rest-done-right-with-steve-klabnik/
przejrzyj te posty:
http://timelessrepo.com/haters-gonna-hateoas
i książkę:
To oczywiście bardzo mądre co piszesz, ale acts_as_api wygrywa tym, że pozwala w czysty sposób (o wiele czyściej niż wiele “true” podejść z tworzeniem widoków) wyeksponować api w bardzo elastyczny sposób. A zestaw ficzerów, składnia i ogólna przyjemność użycia są takie, że wali mnie czy sobie to definiuję akurat jako blok w modelu, czy też miałoby to być w osobnym pliku widoku (niezły pomysł tak w ogóle, może ktoś puści fabrikowi feature albo pull request?).
Z tego co widziałem na wiki da się to wrzucić do osobnego pliku. Później trzeba to zaincludować w modelu i tak, ale przynajmniej nie jest w jednym miejscu.
Co do true podejść, to nie chcę za bardzo spojlować, ale na prezentacji dzisiaj postaram się pokazać jak można prosto użyć własnego kodu w taki sposób, żeby się jakoś strasznie nie narobić ani też nie skończyć na tzw. as_json abuse.
No i tak ogólnie zgadzam się, acts_as_api jest dużo lepsze niż to co jest w 90% aplikacji (także moich ). Tylko coraz bardziej mnie męczą DSLe i kolejne pluginy - często człowiek nawet nie pomyśli, że tak naprawdę, żeby coś takiego zrobić ale używając podejścia OOP, wystarczy dosłownie kilka linijek.
Ja może jestem zepsuty przez Railsy, ale każde “dosłownie kilka linijek” uważam za koszt (utrzymanie, otestowanie itd.), którego jeśli tylko można, to należy uniknąć.
Enyłej, acts_as_api jest tak wygodne pod wszystkimi względami, że jego ewentualna drobna niekoszerność jest dla mnie niezauważalna. Chociaż jasne, fajnie by było móc templejty mieć poza plikiem modelu.
O ile później te kilka linijek mniej nie zamieni się w kilkanaście więcej jak już projekt zrobi się za bardzo skomplikowany. Ale to już podpada pod akademicką dyskusję, więc jak jeszcze trochę podrasuję moje podejście i przeoram bardziej w praktyce, to możemy wrócić do tematu.
Odświeże troche temat, próbował ktoś https://github.com/filtersquad/rocket_pants ?
Wspomniany wyżej RABL https://github.com/nesquena/rabl kusi tym że mamy API ładnie wydzielone w osobnych widokach i można go też używać razem z grape https://github.com/LTe/grape-rabl
Na temat grape się już wypowiadałem, imho niepotrzebna dodatkowa warstwa. Co do rabla, to moim zdaniem przyda się tylko w bardzo specyficznych przypadkach. DHH chce wrzucić do railsów JSON buildera, więc być może będzie coś takiego out of the box, ale ja dużo bardziej wolę używać presenterów.
Widziałem Twoją prezentacje http://vimeo.com/33959660 ,trafiłem też dzis na taki post http://www.quickleft.com/blog/presenters-as-a-solution-to-asjson-woes-in-rails-apis.
Tutaj podejście z decoratorami http://techblog.tribesports.com/blog/2011/09/24/separating-api-logic-with-decorators/
W jakich specyficznych przypadkach widzisz przewagę RABLa ?
Temat API ostatnio modny na blogach 
czyżby coraz więcej aplikacji przenosiło sie w kierunku javascript (backbone itp) + API ?
[quote=Artur79]Widziałem Twoją prezentacje http://vimeo.com/33959660 ,trafiłem też dzis na taki post http://www.quickleft.com/blog/presenters-as-a-solution-to-asjson-woes-in-rails-apis.
Tutaj podejście z decoratorami http://techblog.tribesports.com/blog/2011/09/24/separating-api-logic-with-decorators/[/quote]
Presentery, to w zasadzie są “wyspecjalizowane” dekoratory (dekoratory, które prezentują dane), więc na jedno wychodzi
W przypadku kiedy musisz zbudować jakąś bardzo specyficzną odpowiedź z wieloma asocjacjami, kilkoma poziomami itp. itd. W większości API pewnie się rzadko zdarzy.
Zdecydowanie. A nawet jeżeli nie masz klienta w JS, to API warto mieć.
jakby ktoś miał mało czytania to tutaj ciekawe podejście do wersjonowania API http://techblog.tribesports.com/blog/2011/09/24/versioning-the-tribesports-api/ poprzez własny mime type i renderer
Mam pytanie, próbowałbym robić API za pomocą acts_as_api lub na podstawie prezentacji @drogusa.
Będe potrzebował jakoś authoryzować użytkownika. Co proponujecie na początek z możliwością późniejszej rozbudowy ? Myślałem o Devisowym authentication_token http://www.hyperionreactor.net/blog/token-based-authentication-rails-3-and-rails-2 a potem dodaniu OAuth2. Czy nie będzie problemów ze spięciem tego w wymienionych wyżej podejściach ?
Druga sprawa, to jeśli już użytkownik zostanie “zalogowany” przez API, to chciałbym jak w normalnych kontrolerach używać CanCan’a, nie będzie problemu ?
[quote=Artur79]Mam pytanie, próbowałbym robić API za pomocą acts_as_api lub na podstawie prezentacji @drogusa.
Będe potrzebował jakoś authoryzować użytkownika. Co proponujecie na początek z możliwością późniejszej rozbudowy ? Myślałem o Devisowym authentication_token http://www.hyperionreactor.net/blog/token-based-authentication-rails-3-and-rails-2 a potem dodaniu OAuth2. Czy nie będzie problemów ze spięciem tego w wymienionych wyżej podejściach ?
Druga sprawa, to jeśli już użytkownik zostanie “zalogowany” przez API, to chciałbym jak w normalnych kontrolerach używać CanCan’a, nie będzie problemu ?[/quote]
nie
też już zdążyłem sprawdzić i wszystko ładnie chodzi