Pozostałe interfejsy API - wyzwania specyficzne dla urządzeń mobilnych

Pracuję nad nowym projektem aplikacji na iOS po stronie mobilnej. Trwają pewne zmiany architektury i okazuje się, że będziemy musieli polegać na niestandardowym, prywatnym interfejsie API, który będzie używany przez aplikację, którą tworzymy, a także przez innych klientów, takich jak strona internetowa.

Zaprojektowany interfejs API jest zgodny ze stylem Rest operacji URI i CRUD zorientowanych na zasoby odwzorowanych na czasowniki HTTP. rzeczy jak:

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

Problem polega na tym, że ten styl często powoduje, że klient mobilny musi wykonywać wiele żądań ładowania pojedynczego ekranu aplikacji lub zarządzania pojedynczym działaniem interfejsu użytkownika. To powoduje, że aplikacja jest w trybie ładowania przez 8 sekund, aż będzie miała wszystko, czego potrzeba. Wolna i niereagująca aplikacja.

Klienci mobilni mają poważne ograniczenia, jeśli chodzi o łączność, dlatego najlepiej jest przestrzegać takiej zasady:

1 ekran == 1 wywołanie API

1 zapis == 1 wywołanie API.

Istnieje wiele sytuacji, w których stawia Cię kurs kolizyjny z zasadami projektowania REST, na przykład:

• powiedzmy, że Twoja aplikacja była offline przez jeden dzień i musisz zsynchronizować się z czterema tabelami baz danych zaplecza i potrzebujesz połączenia takiego jak www.example.com/sync_everything?since=2015-07-24
• powiedzmy, że jest ekran, na którym użytkownik może edytować wiele swoich obiektów, na przykład zaznaczanie zadań na swojej liście zadań. powinien istnieć sposób edycji wszystkich tych rekordów zadań w jednym pojedynczym wywołaniu interfejsu API zamiast jednego wywołania interfejsu API na edycję.
• powiedzmy, że jest ekran, który miesza informacje z tabel db ORDER, SALESMEN i PRODUCT, powinienem uzyskać te dane w jednym wywołaniu zamiast trzech.

istnieje ryzyko, że możemy skończyć z najbardziej restrykcyjnym interfejsem API, jaki istnieje, a także z najbardziej bezużyteczną, niereagującą aplikacją mobilną.

Chodzi o to, że jestem tam tylko nowym kontrahentem i potrzebuję czegoś, co pomogłoby mi przedstawić te punkty, niektóre artykuły z cenionych źródeł lub coś w tym rodzaju. Główni gracze kompromitują się ze stylem REST dla swojego klienta mobilnego (np. Poprzez użycie punktów końcowych zagregowanego API złożonego).

Lub jakiekolwiek rozwiązanie tego ogólnego problemu. Dzięki!

Zaprojektowany interfejs API jest zgodny ze stylem Rest operacji URI i CRUD zorientowanych na zasoby odwzorowanych na czasowniki HTTP.

To jest twój problem tutaj.

Ograniczyłeś swoje zasoby do (zakładam) modeli w bazie danych. W związku z tym ładowanie wszystkich tych zasobów trwa wieki, ponieważ twój serwer nie ma pojęcia o zasobach, które nie mają reprezentacji w bazie danych.

Na przykład może mieć

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

wszystkie muszą zostać załadowane, aby uzyskać moją bibliotekę

To nie jest problem z RESTful design, to jest faktycznie anty-wzorzec REST. W REST absolutnie nic nie mówi, że nasze zasoby muszą mieć mapowanie jeden na jeden z czymkolwiek innym w twoim systemie, w tym modelami baz danych.

Rozwiązaniem jest utworzenie większej liczby zasobów, które lepiej pasują do tego, co chcesz załadować. Jeśli masz 5 zasobów, które zawsze kończą się razem, utwórz nowy zasób zawierający informacje o tych 5 zasobach.

Powinieneś mieć coś takiego

www.example.com/users/334/my_library

który po prostu ładuje wszystkie książki dla tego użytkownika. „moja_biblioteka” nie jest modelem w bazie danych, ale jest zasobem. Serwer tworzy go na podstawie modeli w bazie danych, ale nie ma mapowania 1 do 1, a serwer ma elastyczność w tworzeniu tego zasobu bez zmiany modelu DB.

Ty też możesz mieć

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

z których żaden nie musi istnieć jako model w bazie danych lub przestrzeni domeny.

Istnieje powszechne błędne przekonanie, że jest to niewłaściwa rzecz, ponieważ frameworki, takie jak Rails, nauczyły ludzi mapowania zasobów w sposób 1: 1 na modele w przestrzeni domeny, które ponownie mapują 1: 1 z wierszami bazy danych. Nie jest to konieczne ani zalecane.

Zasoby powinny być liczne, tanie i lekkie . Utworzenie ich powinno być łatwe i powinny zostać wyodrębnione z modelu domeny. Jeśli uznasz, że potrzebujesz nowego, po prostu stwórz nowy. Jeśli masz problemy z robieniem tego, jest to wina twoich ram, a nie błąd REST.

Teraz dużym zastrzeżeniem jest to, czy twoje ramy na to pozwalają. Ramy takie jak Rails i Django, które przeszły kurs mapowania 1-do-1 w celu „zaoszczędzenia czasu”, utrudniają to. Jest to jednak wada ram, a nie RESTful.

Oto Jim Webber omawiający to bardziej szczegółowo (w tym także kilka wykopalisk w Railsach!)

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047