Wzorce obsługi operacji wsadowych w usługach internetowych REST?

Jakie sprawdzone wzorce projektowe istnieją dla operacji wsadowych na zasobach w ramach usługi sieci Web w stylu REST?

Staram się znaleźć równowagę między ideałami a rzeczywistością pod względem wydajności i stabilności. Mamy teraz API, w którym wszystkie operacje pobierają z zasobu listy (tj: GET / user) lub na pojedynczej instancji (PUT / user / 1, DELETE / user / 22, itd.).

W niektórych przypadkach chcesz zaktualizować jedno pole z całego zestawu obiektów. Przesyłanie całej reprezentacji każdego obiektu tam iz powrotem w celu zaktualizowania jednego pola wydaje się bardzo marnotrawstwem.

W interfejsie API w stylu RPC możesz mieć metodę:

/mail.do?method=markAsRead&messageIds=1,2,3,4... etc. 

Jaki jest tutaj odpowiednik REST? A może od czasu do czasu można pójść na kompromis. Czy dodanie kilku konkretnych operacji, w których naprawdę poprawia wydajność, itp. Psuje projekt? Klientem we wszystkich przypadkach jest obecnie przeglądarka internetowa (aplikacja javascript po stronie klienta).

Prostym wzorcem RESTful dla partii jest użycie zasobu kolekcji. Na przykład, aby usunąć kilka wiadomości jednocześnie.

DELETE /mail?&id=0&id=1&id=2

Trochę bardziej skomplikowane jest zbiorcze aktualizowanie częściowych zasobów lub atrybutów zasobów. Oznacza to, że zaktualizuj każdy atrybut selectedAsRead. Zasadniczo zamiast traktować atrybut jako część każdego zasobu, traktujesz go jako zasobnik, w którym można umieścić zasoby. Jeden przykład został już opublikowany. Poprawiłem to trochę.

POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]

Zasadniczo aktualizujesz listę wiadomości oznaczonych jako przeczytane.

Możesz również użyć tego do przypisania kilku elementów do tej samej kategorii.

POST /mail?category=junk
POSTDATA: ids=[0,1,2]

Oczywiście dużo bardziej skomplikowane jest wykonywanie częściowych aktualizacji w stylu iTunes (np. Wykonawca + tytuł albumu, ale nie tytuł utworu). Analogia wiadra zaczyna się załamywać.

POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]

W dłuższej perspektywie znacznie łatwiej jest zaktualizować pojedynczy częściowy zasób lub atrybuty zasobów. Wystarczy skorzystać z zasobu podrzędnego.

POST /mail/0/markAsRead
POSTDATA: true

Alternatywnie możesz użyć sparametryzowanych zasobów. Jest to mniej powszechne we wzorcach REST, ale jest dozwolone w specyfikacjach URI i HTTP. Średnik dzieli poziomo powiązane parametry w zasobie.

Zaktualizuj kilka atrybutów, kilka zasobów:

POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk

Zaktualizuj kilka zasobów, tylko jeden atrybut:

POST /mail/0;1;2/markAsRead
POSTDATA: true

Zaktualizuj kilka atrybutów, tylko jeden zasób:

POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk

RESTful kreatywności jest mnóstwo.

Wcale nie - myślę, że odpowiednik REST to (lub przynajmniej jedno rozwiązanie jest) prawie dokładnie tym - wyspecjalizowany interfejs zaprojektowany z myślą o operacji wymaganej przez klienta.

Przypomina mi się wzorzec wspomniany w książce Crane'a i Pascarello Ajax in Action (nawiasem mówiąc, znakomita książka - bardzo polecana), w której ilustrują one implementację obiektu typu CommandQueue, którego zadaniem jest kolejkowanie żądań w partie i następnie wysyłaj je okresowo na serwer.

Obiekt, o ile dobrze pamiętam, zawierał po prostu tablicę "poleceń" - np. Aby rozszerzyć twój przykład, każdy z nich zawierał polecenie "markAsRead", "messageId" i być może odwołanie do wywołania zwrotnego / handlera function - a następnie zgodnie z harmonogramem lub działaniem użytkownika obiekt polecenia byłby serializowany i wysyłany do serwera, a klient zajmowałby się następczym przetwarzaniem końcowym.

Nie mam pod ręką szczegółów, ale wygląda na to, że kolejka poleceń tego rodzaju byłaby jednym ze sposobów rozwiązania problemu; znacznie zmniejszyłoby to ogólną rozmowę i wyodrębniłoby interfejs po stronie serwera w sposób, który może okazać się bardziej elastyczny w przyszłości.

Aktualizacja : Aha! Znalazłem w Internecie wycinek z tej książki, wraz z próbkami kodu (chociaż nadal sugeruję zakup właściwej książki!). Zajrzyj tutaj , zaczynając od sekcji 5.5.3:

Jest to łatwe do zakodowania, ale może skutkować bardzo małym ruchem na serwerze, co jest nieefektywne i potencjalnie mylące. Jeśli chcemy kontrolować nasz ruch, możemy przechwytywać te aktualizacje i umieszczać je w kolejce lokalnie, a następnie wysyłać je partiami na serwer w wolnym czasie. Prosta kolejka aktualizacji zaimplementowana w JavaScript jest pokazana na liście 5.13. […]

Kolejka obsługuje dwie tablice. queued to tablica indeksowana numerycznie, do której dołączane są nowe aktualizacje. sent jest tablicą asocjacyjną zawierającą aktualizacje, które zostały wysłane do serwera, ale oczekują na odpowiedź.

Oto dwie istotne funkcje - jedna odpowiedzialna za dodawanie poleceń do queue ( addCommand), a druga za serializację i wysyłanie ich do serwera ( fireRequest):

CommandQueue.prototype.addCommand = function(command)
{ 
    if (this.isCommand(command))
    {
        this.queue.append(command,true);
    }
}

CommandQueue.prototype.fireRequest = function()
{
    if (this.queued.length == 0)
    { 
        return; 
    }

    var data="data=";

    for (var i = 0; i < this.queued.length; i++)
    { 
        var cmd = this.queued[i]; 
        if (this.isCommand(cmd))
        {
            data += cmd.toRequestString(); 
            this.sent[cmd.id] = cmd;

            // ... and then send the contents of data in a POST request
        }
    }
}

To powinno cię skłonić do działania. Powodzenia!

Chociaż myślę, że @Alex jest na dobrej drodze, myślę, że koncepcyjnie powinno być odwrotnością tego, co jest sugerowane.

Adres URL to w efekcie „zasoby, na które kierujemy reklamy”, stąd:

    [GET] mail/1

oznacza pobranie rekordu z poczty o identyfikatorze 1 i

    [PATCH] mail/1 data: mail[markAsRead]=true

oznacza załatanie rekordu poczty o id 1. Zapytanie jest „filtrem” filtrującym dane zwracane z adresu URL.

    [GET] mail?markAsRead=true

Więc tutaj prosimy o wszystkie wiadomości już oznaczone jako przeczytane. Zatem [PATCH] na tej ścieżce oznaczałoby „załataj rekordy już oznaczone jako prawdziwe”… co nie jest tym, co próbujemy osiągnąć.

Tak więc metoda wsadowa, zgodnie z tym myśleniem, powinna być:

    [PATCH] mail/?id=1,2,3 <the records we are targeting> data: mail[markAsRead]=true

oczywiście nie mówię, że to jest prawdziwy REST (który nie pozwala na manipulowanie rekordami wsadowymi), raczej jest zgodny z logiką już istniejącą i używaną przez REST.

Twój język, „ Wydaje się bardzo marnotrawny…”, wskazuje mi na próbę przedwczesnej optymalizacji. O ile nie można wykazać, że wysyłanie całej reprezentacji obiektów jest dużym spadkiem wydajności (mówimy o nie do przyjęcia dla użytkowników jako> 150 ms), nie ma sensu próbować tworzyć nowego niestandardowego zachowania API. Pamiętaj, im prostsze API, tym łatwiejsze w użyciu.

W przypadku usuwania wyślij następujące informacje, ponieważ serwer nie musi nic wiedzieć o stanie obiektu przed usunięciem.

DELETE /emails
POSTDATA: [{id:1},{id:2}]

Następna myśl jest taka, że ​​jeśli aplikacja ma problemy z wydajnością dotyczące zbiorczej aktualizacji obiektów, należy rozważyć podział każdego obiektu na wiele obiektów. W ten sposób ładunek JSON jest ułamkiem rozmiaru.

Na przykład podczas wysyłania odpowiedzi w celu zaktualizowania stanu „przeczytane” i „zarchiwizowane” dwóch oddzielnych wiadomości e-mail należy wysłać następujące informacje:

PUT /emails
POSTDATA: [
            {
              id:1,
              to:"[email protected]",
              from:"[email protected]",
              subject:"Try this recipe!",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1t Mustard Powder",
              read:true,
              archived:true,
              importance:2,
              labels:["Someone","Mustard"]
            },
            {
              id:2,
              to:"[email protected]",
              from:"[email protected]",
              subject:"Try this recipe (With Fix)",
              text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1T Mustard Powder, 1t Garlic Powder",
              read:true,
              archived:false,
              importance:1,
              labels:["Someone","Mustard"]
            }
            ]

Rozdzieliłbym zmienne składniki wiadomości e-mail (odczyt, zarchiwizowanie, ważność, etykiety) na osobny obiekt, ponieważ inne (do, od, temat, tekst) nigdy nie byłyby aktualizowane.

PUT /email-statuses
POSTDATA: [
            {id:15,read:true,archived:true,importance:2,labels:["Someone","Mustard"]},
            {id:27,read:true,archived:false,importance:1,labels:["Someone","Mustard"]}
          ]

Innym podejściem, które można zastosować, jest wykorzystanie PATCH. Wyraźne wskazanie, które właściwości zamierzasz zaktualizować, a wszystkie inne należy zignorować.

PATCH /emails
POSTDATA: [
            {
              id:1,
              read:true,
              archived:true
            },
            {
              id:2,
              read:true,
              archived:false
            }
          ]

Ludzie twierdzą, że PATCH należy zaimplementować, dostarczając tablicę zmian zawierającą: akcję (CRUD), ścieżkę (URL) i zmianę wartości. Można to uznać za standardową implementację, ale jeśli spojrzeć na całość REST API, jest to nieintuicyjne rozwiązanie jednorazowe. Ponadto powyższa implementacja to sposób, w jaki GitHub zaimplementował PATCH .

Podsumowując, możliwe jest przestrzeganie zasad RESTful z akcjami wsadowymi i nadal mieć akceptowalną wydajność.

Interfejs API dysku Google ma naprawdę ciekawy system rozwiązania tego problemu ( patrz tutaj ).

Zasadniczo grupują różne żądania w jednym Content-Type: multipart/mixedżądaniu, przy czym każde indywidualne pełne żądanie jest oddzielone określonym separatorem. Nagłówki i parametry zapytania w żądaniu wsadowym są dziedziczone do poszczególnych żądań (tj. Authorization: Bearer some_token), Chyba że zostaną nadpisane w indywidualnym żądaniu.

Przykład : (pobrane z ich dokumentów )

Żądanie:

POST https://www.googleapis.com/batch

Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963

--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8


{
  "emailAddress":"[email protected]",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary


POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8


{
  "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

Odpowiedź:

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "12218244892818058021i"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2


HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35


{
 "id": "04109509152946699072k"
}


--batch_6VIxXCQbJoQ_AATxy_GgFUk--

W operacji takiej jak ta z twojego przykładu kusiłabym się, aby napisać parser zakresu.

Stworzenie parsera, który potrafi odczytać „MessageIds = 1-3,7-9,11,12-15” nie jest zbyt trudne. Z pewnością zwiększyłoby to wydajność ogólnych operacji obejmujących wszystkie wiadomości i jest bardziej skalowalne.

Wspaniały post. Szukałem rozwiązania od kilku dni. Wymyśliłem rozwiązanie polegające na przekazaniu ciągu zapytania z identyfikatorami grup oddzielonych przecinkami, na przykład:

DELETE /my/uri/to/delete?id=1,2,3,4,5

... a następnie przekazanie tego do WHERE INklauzuli w moim SQL. Działa świetnie, ale zastanawiam się, co inni myślą o tym podejściu.

Z mojego punktu widzenia uważam, że Facebook ma najlepszą implementację.

Wysyłane jest pojedyncze żądanie HTTP z parametrem wsadowym i jednym dla tokenu.

W partii jest wysyłany plik json. który zawiera zbiór „wniosków”. Każde żądanie ma właściwość metody (get / post / put / delete / etc ...) irelative_url property (uri of endpoint), dodatkowo metody post i put pozwalają na właściwość "body", w której pola mają być aktualizowane są wysyłane .

więcej informacji na: Facebook batch API