Derby z RESTful API

Question

Jestem bardzo zaintrygowany derby i spędziłem wczoraj noc czytając dokumentację. Moje obecne przemyślenia architektoniczne są bardzo ukierunkowane na tworzenie RESTful API, który jest używany przez odpowiednią aplikację Rich Client lub przez każdego, kto ma dostęp do API.

Derby robi na mnie wrażenie nie tylko ze względu na nacisk na szybkość, ale także dlatego, że działa bardzo podobnie do sieci (z adresami URL pasującymi do stron). Jednak w dzisiejszych czasach, gdy mamy mobilną aplikację, która pasuje do produktu, wydaje się, że posiadanie API jest niezbędne, jeśli chce się rozwijać zarówno w sferze mobilnej, jak i przeglądarkowej.

Moje pytanie jest dwojakie.

1. Można użyć derby do interfejsu API, zasadniczo pisząc adapter API i zamieniając go z mongoadapter. Nie patrzyłem na adapter, ale dokumenty sugerują, że pisanie adaptera nie jest zbyt trudne. Alternatywnie może derby wytworzyć odpowiedź JSON na wywołanie API, jeśli nagłówek accepts prosi o json. W ten sposób może odgrywać rolę jako API wraz z obsługą webapp.

2. Powinien być traktowany jako aplikacja jako całość i nie być w ogóle używany do innych aplikacji (np. Mobilnych). Tj. Wspólnym czynnikiem między przeglądarką a aplikacją mobilną będzie baza danych, a nie API. Minusem braku API jako wspólnego czynnika jest to, że funkcje mogą nie być spójne w różnych aplikacjach (nie w liczbie funkcji, ale jeden może być wadliwy, a drugi nie).

Bardzo chciałbym użyć derby w naszym następnym projekcie, ale potrzebujemy pewności, czy to narzędzie do pracy. (Nawiasem mówiąc projekt będzie duża aplikacja internetowa, ale musi mieć integrację telefonii komórkowej. Mając API może być również świetny pomysł, ale nie jestem pewien, ale jej użyteczność)

Answer 1

1. myślę, że można napisać adapter do derby, aby komunikować się z api-app (gdzie dane faktycznie przechowywane), ale ten adapter będzie miał predefiniowane metody i nie będzie odzwierciedlał twojego API. Tak więc logika biznesowa prawdopodobnie zostanie zduplikowana (aplikacja derby i api), a ty nie zyskasz wiele z tego rozwiązania.

2. Polecam używać derby jako api-app. Od wersji 0.6 (już wkrótce) możesz użyć aplikacji derby po stronie klienta bez strony serwera, co oznacza, że ​​możesz na przykład użyć jej w phonegap. Również derby ma wbudowaną synchronizację klienta z rozwiązywaniem konfliktów w oparciu o share.js. Możesz go używać do aplikacji internetowych i phonegapowych "w pudełku", ale w przypadku natywnych aplikacji mobilnych powinieneś pisać klientów share.js, aby z niego korzystać. Ponadto w apce share.js znajduje się wbudowane api typu rest lub możesz z łatwością implementować api w oparciu o trasy ekspresowe. Derby jest więc idealne do aplikacji api, webowych, phonegapowych i dobrych aplikacji mobilnych.