Bardzo dobrze. +1. Na pewno jest to dla mnie przydatne odniesienie w przyszłości. Również @Aaron i inni dodali wartość do dyskusji. Podobnie jak Ruby, to pytanie dotyczy również innych środowisk programistycznych.

Użyłem dwóch pierwszych opcji. Pierwsza dla wielu aplikacji i druga dla mojego projektu open source Cowoop

Opcja 1

Ten jest bez wątpienia najbardziej popularny. Ale uważam, że implementacja jest bardzo http-owska. Każdy API początkowy kod trafia do obiektu request. Więc kod API jest czymś więcej niż czystym kodem ruby/python/innego języka.

Opcja 2

Zawsze to uwielbiałam.

Opcja ta oznacza również, że HTML nie jest generowany w trybie runtime na serwerze. W ten sposób wariant 2 różni się od wariantu 3. Ale są budowane jako statyczny html za pomocą skryptu budowania. Po załadowaniu po stronie klienta HTML wywoła serwer API jako klient API JS.

• Separacja obawy to wielka zaleta. I bardzo do swoich upodobań (i moje) eksperci backend implementują backend API, testują je łatwo jak zwykły kod języka, nie martwiąc się o kod żądania framework / http.

• To naprawdę nie jest tak trudne, jak brzmi po stronie frontend. Do wywołania API i dane wynikowe (głównie json) są dostępne dla szablonu po stronie klienta lub MVC.

• Mniej przetwarzania po stronie serwera. Oznacza to, że możesz wybrać sprzęt towarowy / tańszy serwer.

• Łatwiej testować warstwy niezależnie, łatwiej generować dokumenty API.

Ma pewne wady.

• Wielu deweloperów uważa to za zbyt zaprojektowane i trudne do zrozumienia. Więc jest szansa, że architektura może zostać skrytykowana.

• I18n / l10n jest twardy. Ponieważ HTML jest zasadniczo generowany czas kompilacji jest statyczny, trzeba wiele kompilacji na obsługiwany język(co niekoniecznie jest złe). Ale nawet dzięki temu możesz mieć narożne skrzynki wokół l10n/i18n i musisz być ostrożny.

Opcja 3

Kodowanie backendu w tym przypadku musi być takie samo jak druga opcja. Większość punktów za wariant 2 ma również zastosowanie w tym przypadku.

Strony WWW są renderowane przy użyciu szablonów po stronie serwera. To sprawia, że i18n/l10n jest znacznie łatwiejsze dzięki bardziej ugruntowanym/zaakceptowanym technikom. Może to być jedno wywołanie http mniej dla jakiegoś niezbędnego kontekstu potrzebnego do renderowania strony, takiego jak użytkownik, język, waluta itp. Tak więc przetwarzanie po stronie serwera jest zwiększane wraz z renderowaniem, ale prawdopodobnie kompensowane przez mniej wywołań http do serwera API.

Teraz, gdy strony są renderowane na serwerze, nakładka jest teraz bardziej powiązana ze środowiskiem programistycznym. Może to nie być nawet brane pod uwagę w przypadku wielu zastosowań.

Sprawa Twittera

Jak rozumiem, Twitter może robić swoje początkowe renderowanie strony na serwerze, ale dla aktualizacji strony nadal ma pewne wywołania API i klienta szablony boczne do manipulowania DOM. W takim przypadku masz podwójne szablony do utrzymania, co dodaje trochę narzutu i złożoności. Nie każdy może sobie pozwolić na tę opcję, w przeciwieństwie do Twittera.

Nasz stos projektu

Tak się składa, że używam Pythona. Używam JsonRPC 2.0 zamiast reszty. Proponuję odpocząć, choć pomysł na JsonRPC Lubię z różnych powodów. Używam poniższych bibliotek. Ktoś rozważający opcję 2/3 może uznać ją za przydatną.

• Serwer API: Python a fast web micro framework - Kolba
• Frontend server: Nginx
• po stronie klienta MVC: nokaut.js
• inne odpowiednie narzędzia / libs:
  • Jquery
  • Księgowość.js for money currency
  • Webshim : Cross browser polyfill
  • dyrektor : routing po stronie klienta
  • sphc : generowanie HTML

Moje wnioski i zalecenia

Opcja 3!.

All said, I have zastosowano wariant 2 z powodzeniem, ale teraz skłaniamy się ku wariantowi 3 dla pewnej prostoty. Generowanie statycznych stron HTML za pomocą skryptu build i serwowanie ich jednym z ultra szybkich serwerów specjalizujących się w serwowaniu statycznych stron jest bardzo kuszące (Opcja 2).

Zdecydowaliśmy się na #2 przy budowaniu gaug.es. pracowałem na API (ruby, sinatra itp.), a mój partner biznesowy, Steve Smith, pracował nad front-endem (klient javascript).

Plusy:

1. Poruszaj się szybko równolegle. Gdybym pracował przed Steve ' em, mógłbym nadal tworzyć interfejsy API dla nowych funkcji. Gdyby pracował przede mną, mógłby bardzo łatwo sfałszować API i zbudować interfejs użytkownika.

2. API za darmo. Otwarty dostęp do danych w aplikacji szybko staje się standardowa funkcja. Jeśli zaczniesz z API od podstaw, otrzymasz to za darmo.

3. Czysta separacja. Lepiej jest myśleć o swojej aplikacji jako API z klientami. Oczywiście, pierwszym i najważniejszym klientem może być klient internetowy, ale ustawia cię do łatwego tworzenia innych klientów (iPhone, Android).

Wady:

1. Zgodność Wsteczna. Jest to bardziej związane z API niż bezpośrednie pytanie, ale gdy API już tam jest, nie możesz go po prostu złamać albo złamiesz dwóch klientów. Nie oznacza to, że musisz poruszać się wolniej, ale oznacza to, że często musisz sprawić, by dwie rzeczy działały jednocześnie. Dodawanie do API lub nowych pól jest w porządku, ale zmiana/usunięcie nie powinno odbywać się bez wersjonowania.

Nie mogę teraz myśleć o kolejnych przekrętach.

Wniosek: API + klient JS jest dobrym rozwiązaniem, jeśli planujesz wydać API.

P. S. polecam również pełne udokumentowanie swojego API przed jego wydaniem. Proces dokumentowanie Gaug.es API naprawdę pomógł nam Imp

Http://get.gaug.es/documentation/api/

Wolę iść trasą #2 i # 3. Głównie dlatego, że #1 narusza oddzielenie obaw i przeplata wszelkiego rodzaju rzeczy. W końcu znajdziesz potrzebę posiadania punktu końcowego API, który nie ma pasującej strony HTML / etc i będziesz się strumieniować z pomieszanymi punktami końcowymi HTML i JSON w tej samej bazie kodu. To zamienia się w cholerny bałagan, nawet jeśli jego MVP, będziesz musiał w końcu napisać go ponownie, ponieważ jego tak brudny, że nawet nie warto go uratować.

Idąc z # 2 lub # 3 pozwala całkowicie mieć API, które działa tak samo (w większości przypadków) niezależnie. Zapewnia to dużą elastyczność. Nie jestem w 100% sprzedawany na Backbone/ember / whatever / etc.js jeszcze nie. Myślę, że jest świetny, ale jak widzimy z Twittera nie jest to optymalne. Ale... Twitter jest również ogromną bestią firmy i ma setki milionów użytkowników. Tak więc każda poprawa może mieć ogromny wpływ na wyniki finansowe w różnych obszarach różnych jednostek biznesowych. Myślę, że decyzja jest czymś więcej niż tylko szybkością i nie wpuszczą nas w to. Ale to tylko moje zdanie. Nie dyskontuję jednak szkieletu i jego konkurentów. Te aplikacje są świetne w użyciu i są bardzo czyste i są bardzo responsywne (w większości).

Trzecia opcja ma również pewien ważny urok. To jest miejsce, w którym kieruję się zasadą Pareto (reguła 80/20) i mam 20% głównego znacznika (lub odwrotnie) renderowane na serwerze, a następnie mieć ładny klient JS (backbone/etc) uruchomić resztę. Możesz nie być komunikowanie się w 100% z REST api za pośrednictwem klienta JS, ale w razie potrzeby wykonasz trochę pracy, aby ulepszyć doświadczenie suer.

Myślę, że jest to jeden z tych problemów typu "to zależy", a odpowiedź brzmi "to zależy" od tego, co robisz, komu służysz i jakiego rodzaju doświadczenia chcesz, aby otrzymali. Biorąc pod uwagę, że myślę, że można zdecydować między 2 lub 3 lub hybrydy z nich.

Obecnie pracuję nad konwersją ogromnego CMS z opcji 1 do opcji 3, i idzie dobrze. Zdecydowaliśmy się na renderowanie znaczników po stronie serwera, ponieważ SEO jest dla nas dużym problemem i chcemy, aby witryny działały dobrze na telefonach komórkowych.

Używam node.js dla zaplecza klienta i garść modułów, które mi pomogą. Jestem nieco na początku tego procesu, ale fundament jest ustawiony i to kwestia przejrzenia danych, zapewniając, że wszystko będzie dobrze. Oto, czego używam:

• Express dla Fundacji aplikacji.
  (https://github.com/visionmedia/express)
• Prośba o pobranie danych.
  (https://github.com/mikeal/request)
• Szablony podkreślenia, które są renderowane po stronie serwera. Używam ich ponownie na kliencie.
  (https://github.com/documentcloud/underscore)
• UTML zawija szablony podkreślenia, aby działały z Expressem.
  (https://github.com/mikefrey/utml)
• Upfront zbiera szablony i pozwala wybrać które są wysyłane do klienta.
  (https://github.com/mrDarcyMurphy/upfront)
• Express Expose przekazuje pobrane dane, niektóre moduły i szablony do front-endu.
  (https://github.com/visionmedia/express-expose)
Backbone tworzy modele i widoki na front-endzie po przełknięciu danych, które zostały przekazane.
(https://github.com/documentcloud/backbone)

To jest rdzeń stosu. Kilka innych modułów, które uznałem za pomocne:

• fleck (https//github.com / trek / fleck)
Moment (https / / github. com / timrwood / moment) [[5]}stylus (https//github.com/LearnBoost/stylus) [[5]}smoosh (https//github.com/fat/smoosh)
...chociaż patrzę na grunt (https//github.com/cowboy/grunt)
• Console trace (//github.com/LearnBoost/console-trace).

Nie, Nie używam coffeescript.

Ta opcja działa naprawdę dobrze dla mnie. Modele na zapleczu nie istnieją, ponieważ dane, które otrzymujemy z API jest dobrze skonstruowane i przekazuję je dosłownie do front-endu. Jedynym wyjątkiem jest nasz model Układu, w którym dodaję jeden atrybut, który sprawia, że rendering jest inteligentniejszy i lżejszy. Nie używałem do tego żadnej fantazyjnej biblioteki modeli, po prostu funkcji, która dodaje to, czego potrzebuję przy inicjalizacji i zwraca się sama.

(sorry za dziwne linki, jestem za duzo n00b dla stack overflow zeby pozwolic mi wrzucic tyle)

Używamy następującego wariantu #3: Stwórz serwer REST API tylko dla JSON. Stwórz serwer WWW HTML. HTML web server nie jest, jak w Twoim wariancie, klientem serwera REST API. Zamiast tego obaj są rówieśnikami. Nie daleko pod powierzchnią znajduje się wewnętrzne API, które zapewnia funkcjonalność, której potrzebują oba serwery.

Nie znamy żadnego precedensu, więc to trochę eksperymentalne. Jak do tej pory (zaraz wejdzie do bety), wyszło całkiem nieźle.

Zazwyczaj wybieram drugą opcję, używając Railsów do budowania API i szkieletu dla rzeczy JS. Możesz nawet uzyskać panel administracyjny za darmo za pomocą ActiveAdmin . Wysłałem dziesiątki aplikacji mobilnych z tego rodzaju backendem. Jednak zależy to w dużej mierze od tego, czy Twoja aplikacja jest interaktywna, czy nie.

Zrobiłem prezentację na temat tego podejścia na ostatnim RubyDay.it: http://www.slideshare.net/matteocollina/enter-the-app-era-with-ruby-on-rails-rubyday

Dla trzecia opcja, aby uzyskać responsywność drugiej, możesz spróbować pajax tak jak robi to Github.

Jestem około 2 miesięcy w 3-miesięcznym projekcie, który ma drugie podejście, które opisałeś tutaj. Używamy RESTful API server side z backbone.js z przodu. Kierownica.js zarządza szablonami, a jQuery obsługuje manipulację AJAX i DOM. W przypadku starszych przeglądarek i pająków wyszukiwania powróciliśmy do renderowania po stronie serwera, ale używamy tych samych szablonów HTML, co nakładka na kierownicę za pomocą Mozilli Rhino.

Wybraliśmy to podejście z wielu różnych powodów, ale są bardzo świadomy, że jest to trochę ryzykowne, biorąc pod uwagę, że nie zostało jeszcze udowodnione na szeroką skalę. Jak na razie wszystko idzie gładko.

Do tej pory pracowaliśmy tylko z jednym API, ale w następnej fazie projektu będziemy pracować z drugim API. Pierwszy dotyczy dużych ilości danych, a drugi działa bardziej jak CMS za pośrednictwem API.

To, że te dwa elementy projektu działają całkowicie niezależnie od siebie, było kluczowym czynnikiem przy wyborze tego Infrastruktura. Jeśli szukasz architektury do mashup różnych niezależnych zasobów bez żadnych zależności, to warto zajrzeć.

Obawiam się, że nie jestem facetem Ruby, więc nie mogę komentować innych podejść. Czasem warto zaryzykować. Innym razem lepiej grać bezpiecznie. Będziesz sam w zależności od rodzaju projektu.

Powodzenia w wyborze tutaj. Chętnie zobaczę, co inni też dzielą.

Lubię #3, gdy moja strona nie będzie 100% implementacją CRUD moich danych. Co jeszcze się stanie.

Wolę Sinatrę i po prostu podzielę aplikację na kilka różnych aplikacji rack o różnych celach. Zrobię API specyficzną aplikację rack, która obejmie to, czego potrzebuję do API. Następnie może aplikacja rack użytkownika, który zaprezentuje moją stronę. Czasami ta wersja zapyta API w razie potrzeby, ale zwykle dotyczy tylko strony html.

I don ' t martw się o to i po prostu wykonaj zapytanie warstwy persistance od strony użytkownika, jeśli tego potrzebuję. Nie przejmuję się zbytnio tworzeniem kompletnej separacji, ponieważ zazwyczaj służą one różnym celom.

Oto bardzo prosty przykład korzystania z wielu aplikacji rack. Dodałem tam szybki przykład jquery, aby zobaczyć, jak uderza w aplikację API. Możesz zobaczyć, jak proste może to być z sinatra i montażu wielu aplikacji rack z różnych cele.

Https://github.com/dusty/multi-rack-app-app

Kilka świetnych odpowiedzi tutaj już-zdecydowanie polecam #2 lub # 3-separacja jest dobra koncepcyjnie, ale także w praktyce.

Może być trudno przewidzieć takie rzeczy, jak wzorce obciążenia i ruchu na API, a klienci, którzy obsługują API niezależnie, mają łatwiejszy czas Aprowizacji i skalowania. Jeśli trzeba to zrobić w oparciu o ludzkie wzorce dostępu do sieci jest to mniej proste. Również użycie API może skończyć się skalowanie się znacznie szybciej niż klient sieci web, a następnie można zobacz, gdzie kierować swoje wysiłki.

Między # 2 # 3 to naprawdę zależy od celów - zgadzam się, że #2 jest prawdopodobnie przyszłość webapps - ale może chcesz coś bardziej prostego, jeśli ten kanał jest tylko będzie jednym z wielu!

Dla atyourservice.com.cy używamy renderowanych po stronie serwera szablonów stron, szczególnie w celu pokrycia części se. I korzystanie z API do interakcji po załadowaniu strony. Ponieważ nasz framework jest MVC wszystkie funkcje kontrolera są duplikowane do wyjścia json i wyjścia html. Szablony są czyste i otrzymują tylko obiekt. Można to przekształcić w szablony js w kilka sekund. Zawsze utrzymujemy szablony po stronie serwera i po prostu rekonwertuj do js na żądanie.

Renderowanie izomorficzne i stopniowe Ulepszanie. Myślę, że właśnie do tego zmierzałeś w opcji trzeciej.

Renderowanie izomorficzne oznacza użycie tego samego szablonu do generowania znaczników po stronie serwera, jakiego używasz w kodzie po stronie klienta. Wybierz język szablonów z dobrymi implementacjami po stronie serwera i klienta. Stwórz w pełni wypiekany html dla swoich użytkowników i wyślij go w dół przewodu. Użyj też buforowania.

Progressive enhancement oznacza rozpoczęcie pracy po stronie klienta wykonanie i renderowanie oraz nasłuchiwanie zdarzeń po pobraniu wszystkich zasobów i określeniu możliwości klienta. Powrót do funkcjonalności bez skryptów klienckich, w miarę możliwości dla dostępności i kompatybilności wstecznej.

Tak, oczywiście napisać samodzielny JSON api dla tej funkcjonalności aplikacji. Ale nie posuwaj się tak daleko, że piszesz json api dla rzeczy, które działają dobrze jako statyczne dokumenty html.

REST server + JavaScript-ciężki klient był zasadą, którą stosowałem w mojej ostatniej pracy.

Rest server został zaimplementowany w node.js + Express + MongoDB (Bardzo dobra wydajność pisania) + Mongoose ODM (świetnie nadaje się do modelowania danych, w tym walidacji) + CoffeeScript (zamiast tego wybrałbym ES2015), który działał dobrze dla mnie. Węzeł.js może być stosunkowo młody w porównaniu z innymi możliwymi technologiami po stronie serwera, ale umożliwił mi napisać solidne API ze zintegrowanymi płatnościami.

Użyłem Ember.js jako framework JavaScript i większość logiki aplikacji została wykonana w przeglądarce. Używałem SASS (konkretnie SCSS) do wstępnego przetwarzania CSS.

Ember Core Zespół jest w trakcie opracowywania FastBoot , który pozwoli Ci wykonać logikę JavaScript Ember po stronie serwera (node.w szczególności js) i wysłać wstępnie renderowany HTML aplikacji (który normalnie byłby uruchamiany w przeglądarce) do użytkownika. Jest to świetne dla SEO i doświadczenia użytkownika, ponieważ nie czeka tak długo na wyświetlenie strony.

Ember CLI to świetne narzędzie, które pomaga uporządkować kod i dobrze się skalowało wraz z rosnącą bazą kodową. Ember ma również własny dodatek ekosystem i możesz wybierać spośród różnych dodatków Ember . Możesz łatwo chwycić Bootstrap (w moim przypadku) lub Fundacji i dodać go do swojej aplikacji.

upstream app_appName.com {
  # replace 0.0.0.0 with your IP address and 1000 with your port of node HTTP server
  server 0.0.0.0:1000;
  keepalive 8;
}

server {
  listen 80 default_server;
  listen [::]:80 default_server ipv6only=on;

  client_max_body_size 32M;

  access_log  /var/log/nginx/appName.access.log;
  error_log  /var/log/nginx/appName.error.log;

  server_name appName.com appName;

  location / {
     # frontend assets path
     root /var/www/html;
     index index.html;

     # to handle Ember routing
     try_files $uri $uri/ /index.html?/$request_uri;
  }

  location /i/ {
    alias /var/i/img/;
  }

  location /api/v1/ {
    proxy_pass  http://app_appName.com;

    proxy_next_upstream error timeout invalid_header http_500 http_502
http_503 http_504;
    proxy_redirect off;
    proxy_buffering off;
    proxy_set_header        Host            $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Pro: uwielbiam rozdzielanie API i klienta. Mądrzy ludzie mówią, że to jest droga do wyjścia. Świetny w teorii. Wydaje się nowatorskie i ekscytujące.

I można powiedzieć, że jest to również świetne w praktyce. Kolejną zaletą oddzielenia REST API jest to, że można go później ponownie wykorzystać w innych aplikacjach. W perfect world powinieneś być w stanie używać tego samego REST API nie tylko dla strony internetowej, ale także dla aplikacji mobilnych, jeśli zdecydujesz się go napisać.

Con: niewiele precedensu. Niewiele przykładów tego dobrze się sprawdziło. Publiczne przykłady (twitter.com) poczują się ospali i nawet odchodzą od takie podejście.

Things look different teraz. Istnieje wiele przykładów robienia REST API + wielu klientów korzystających z niego.

Zdecydowałem się na architekturę opcji # 2 dla Infiniforms , ponieważ zapewniła ona świetny sposób na oddzielenie interfejsu użytkownika od logiki biznesowej.

Zaletą tego jest to, że serwery API mogą skalować się niezależnie od serwerów WWW. Jeśli masz wielu klientów, witryny internetowe nie będą musiały skalować się w takim samym stopniu, jak serwery internetowe, ponieważ niektóre pomyje klientów są oparte na telefonie / tablecie lub komputerze.

To podejście daje również dobrą podstawę do otwierania API użytkownikom, zwłaszcza jeśli korzystasz z własnego API, aby zapewnić wszystkie funkcje swojej witryny.

Bardzo ładne pytanie i jestem zaskoczony, ponieważ myślałem, że jest to bardzo powszechne zadanie w dzisiejszych czasach, tak że będę miał mnóstwo środków na ten problem, jednak okazało się, że nie jest to prawda.

module WebAndAPICommon
    module Products

        def index
            @products = # do some logic here that will set @products variable
        end

    end
end


class ProductsController < ApplicationController
    # default products controlelr, for rendering HMTL pages 
    include WebAndAPICommon

    def index
        super
    end

end



module API
    class ProductsController
        include WebAndAPICommon

        def index
            super
            render json: @products
        end

    end
end

Wybrałem podejście hybrydowe, w którym używamy Sinatry jako bazy, ActiveRecord / Postgress itp., Aby Obsługiwać trasy stron (slim templates). We wczesnych pracach programistycznych, takich jak wypełnianie opcji select, odbywa się poprzez renderowanie helperów do szablonu slim, ale w miarę zbliżania się do produkcji zostaje to zamienione na wywołanie AJAX do REST API, ponieważ zaczynamy bardziej dbać o szybkość ładowania strony i tak dalej.

Rzeczy, które łatwo wyrenderować W Slim dostaje obsługiwane w ten sposób, i rzeczy (wypełnianie formularzy, odbieranie danych formularza z jQuery.Validation ' s submitHandler etc, is all abviously AJAX)

Testowanie jest problemem. W tej chwili jestem zakłopotany próbując przekazać dane JSON do racka::Test POST test.

Osobiście wolę opcję (3) jako rozwiązanie. Jest używany w prawie wszystkich miejscach, które mój były (nazwa gospodarstwa domowego) pracodawca ma. Oznacza to, że możesz uzyskać programistów front-end, którzy wiedzą wszystko o Javascript, dziwactwach przeglądarki i tym podobnych, aby zakodować swój front-end. Muszą tylko wiedzieć "curl xyz i dostaniesz json" i odchodzą.

W międzyczasie, twoi ciężcy back-endowi faceci mogą kodować dostawców Json. Ci kolesie wcale nie muszą myśleć o prezentacji i zamiast tego martw się o flaky backends, timeouts, wdzięczną obsługę błędów, pule połączeń z bazami danych,wątki i skalowanie itp.

Opcja 3 daje dobrą, solidną architekturę trójwarstwową. Oznacza to, że rzeczy, które wypluwasz z przodu, są przyjazne dla SEO, mogą być przystosowane do pracy ze starymi lub nowymi przeglądarkami( i tymi z wyłączonym JS) i nadal mogą być szablonami po stronie klienta Javascript, jeśli chcesz (więc możesz robić rzeczy takie jak obsługa starych przeglądarek / googlebot ze statycznym HTML, ale wyślij js wbudowany dynamiczne doświadczenia dla osób korzystających z najnowszej przeglądarki Chrome lub cokolwiek innego).

We wszystkich przypadkach widziałem opcję 3, była to niestandardowa implementacja jakiegoś PHP, który nie jest szczególnie przenoszalny między projektami, nie mówiąc już o Open Source land. Myślę, że ostatnio PHP mogło zostać zastąpione Ruby / Rails, ale to samo jest nadal prawdą.

FWIW, $current_employer przydałaby się opcja 3 w kilku ważnych miejscach. Szukam dobrego frameworka Ruby w którym można coś zbudować. Jestem pewien, że mogę skleić ze sobą ładunek klejnotów, ale wolałbym pojedynczy produkt, który zasadniczo zapewnia szablon, "curling", opcjonalne uwierzytelnianie, opcjonalne rozwiązanie buforowania memcache/nosql. Nie znajduję nic spójnego: - (

Jsonapi::Resources gem jest pierwszą klasą, A jsonapi:: Resources gem wykonuje ciężkie zadania dla http://jsonapi.org spec ' d API.