2012-04-27 61 views
7

Mam usługę REST, która obsługuje funkcję faktury, na przykład mogę utworzyć, zaktualizować i usunąć fakturę za pośrednictwem usługi REST.RESTful połączenie i podział zasobów

Jednak teraz potrzebuję funkcji do dzielenia faktury na kilka nowych faktur, tj. Metoda musi utworzyć x faktury na podstawie jednej faktury, a następnie usunąć oryginalną fakturę w jednej transakcji.

Potrzebuję również metody scalania, która działa odwrotnie, tj. Wielu faktur scalonych w jeden.

Jak utworzyć takiego architekta w trybie RESTOWN?

Odpowiedz

4

Mieliśmy podobny problem, gdy chcieliśmy połączyć 2 zasoby. Po długiej debacie zdecydowaliśmy, że konsument będzie POST zasób żądania scalenia, który zawierał dwa zasoby do połączenia. Następnie, patrząc na to, zdecydowaliśmy, że nie ma potrzeby korzystania zarówno z kompletnego zasobu źródłowego, jak i docelowego, a zamiast tego wystarczyło POST tylko jednego unikalnego identyfikatora. Nie złożyliśmy wniosku o scalenie tylko z 2 identyfikatorami w ciele. Łatwiej było reprezentować w adresie URL, więc to, co zrobiliśmy. Odpowiedź z POSTING żądania scalenia jest połączonym zasobem.

Chyba nie jestem guru REST, który mógłby ci powiedzieć, że to dobra strategia, ale dla nas to było proste rozwiązanie, więc poszliśmy z tym.

2

Kiedy mówisz, że chcesz zaimplementować tę funkcję w "jednej transakcji", zakładam, że już wiesz, że powinieneś łączyć generowanie nowych faktur i usuwanie starego w jedno wywołanie API; co jest właściwym podejściem. Z usługami sieciowymi chcesz zmniejszyć rozmowę i prawdopodobnie istnieje pewna logika biznesowa dotycząca sposobu, w jaki ta funkcja wygeneruje nowe faktury i usunie starą. Zakładam więc, że kiedy zapytasz, jak zaprojektować to w RESTOWNOWY sposób, zastanawiasz się, który czasownik HTTP użyć (tj. GET, POST, PUT lub DELETE) dla tej nowej metody API. Zwykle te czasowniki map do operacji typu CRUD w następujący sposób:

  • Create -> POST
  • Odczyt -> GET
  • Aktualizacja -> PUT
  • Usuń -> Usuń

Więc który czasownik należy użyć, gdy twoja funkcja zarówno tworzy, jak i usuwa rekordy. Ogólna reguła z REST API polega na tym, że nie ma wyraźnego odwzorowania na CRUD, a następnie użyj POST, jeśli jest zmiana stanu serwera i GET, jeśli właśnie zwracasz informacje, które nie zmieniają stanu serwera. Więc w tym przypadku pójdę z POST.

Jeśli poszukujesz dodatkowych wskazówek na temat tego projektowania, prosimy o bardziej szczegółowe informacje o tym, czego szukasz, a ja postaram się pomóc.

+0

Cześć Kevin, można zaproponować w jaki sposób url powinien wyglądać dla tych operacji dzielenia/łączących? –

-1

chciałbym zrobić coś takiego,

POST /InvoiceSplitter?sourceInvoiceId=99 

i

POST /InvoiceMerger?sourceInvoiceIds=101,87,23,45 
+1

Te adresy URL nie wyglądają na szczególnie spokojne, jeśli identyfikujesz zasoby według jakiegoś identyfikatora, a nie według ścieżki URL. Zrobiłbym coś w rodzaju 'POST/path/to/invoice/99? Split = true' lub dla scalenia' POST/path/to/invoice/99? MergeWith =/path/to/invoice/101' –

+0

@AlexanderKlimetschek Istnieje nie ma czegoś takiego, jak RESTNY URL.Używam pojęcia "zasobu przetwarzania" zdefiniowanego w specyfikacji HTTP. Twoje przykłady też są w porządku. Jednak upewnij się, że unikniesz ukośnika dla wartości parametru łańcucha zapytania. –

Powiązane problemy