Co to jest RESTful-resource w kontekście dużych zbiorów danych, i.E. dane pogodowe?

Question

Pracuję więc nad serwisem internetowym, aby uzyskać dostęp do naszych danych dotyczących prognozy pogody (10000 lokalizacji, po 40 parametrów, wartości godzinne w ciągu najbliższych 14 dni = około 130 milionów wartości).

Więc czytam wszystko o usługach REST i ich ideologii.

Rozumiem, że adres URL jest adresowany do źródła.

Ale co jest ressource w moim przypadku?

Powszechnie stosowanym przypadkiem jest to, że chcesz uzyskać dane dla kilku parametrów w określonym czasie w jednej lub wielu lokalizacjach. Tak więc wyraźne nadanie każdej wartości własnego adresu URL nie jest praktyczne i skutkowałoby setkami próśb. Mam wrażenie, że mój konkretny problem nie pasuje idealnie do wzorca REST.

Aktualizacja: Wyjaśnienie: Istnieją dwa sposoby korzystania z usługi. 1. Surowe dane; wiersze i wiersze danych dla kilku lokalizacji i parametrów.

2. Zinterpretowane dane; surowe dane obliczone na symbole (na przykład chmury Suns) i inne parametry.

Nie ma jednej "prognozy". Różni klienci mają różne potrzeby dotyczące danych.

Powodem, dla którego myślę, że to nie pasuje do wzorca REST, jest to, że chociaż mogę faktycznie mieć "prognozy" ressource, nadal muszę przesłać wiele parametrów żądania. Więc proste żądanie GET w ressource nie działa, kończę dane POSTing w każdym miejscu.

Answer 1

Więc pracuję nad usługa dostępu do naszych danych prognozy pogody (10000 lokalizacje, po 40 parametrów, wartości godzinne dla kolejnych 14 dni = około 130 milionów wartości). ... Ale co to jest ressource w moim przypadku?

To zależy od szczegółów twojej domeny problemowej. Posiadanie dużej ilości danych nie jest dobrym powodem do unikania REST. Istnieją sprytne sposoby i głupie sposoby modelowania i ujawniania tych danych.

Jak słusznie widzisz, twoim głównym celem na tym etapie powinno być zrozumienie, czym dokładnie jest zasób. Wiedząc tylko tyle o prognozowaniu pogody, żeby śledzić Weather Channel, nie będę tu zbytnio pomocny. To jest dla ekspertów takich jak ty, aby wykonać to połączenie.

Jeśli chcesz wyjaśnić bardziej szczegółowo główne pojęcia związane z domeną, z którymi pracujesz, może to sprawić, że trochę łatwiej będzie udzielić konkretnej porady.

Na przykład jeden zasób może być prognozą. Kiedy pogadusznicy mówią o prognozach, jakie słowa nadchodzą? Kiedy myślisz o podzieleniu prognozy na mniejsze elementy, jakich słów używasz do opisania tych elementów?

Wykonaj ten proces rekursywnie, a prawdopodobnie będziesz mógł utworzyć listę ważnych pojęć. Nie zapominaj, że te terminy mogą opisywać rzeczy lub działania. Zastanów się, co naprawdę oznaczają te terminy, jakich danych możesz użyć do ich modelowania, w jaki sposób można je zagregować.

W tym momencie będziesz mieć zadatki na coś, od czego możesz zacząć budować system RESTful - ale nie wcześniej.

Nie zapominaj, że system RESTful nie jest zrzutem danych zapakowanym w HTTP - jest to system hypertext-driven.

Należy również pamiętać, że media types jest punktem kontaktu między serwerem a klientami. Typ medium jest ograniczony tylko twoją wyobraźnią i może modelować zbiory danych o dowolnym rozmiarze, jeśli jesteś sprytny. Może zawierać XML, JSON, YAML, elementy binarne, takie jak Bloom Filter lub cokolwiek działa na problem.

Answer 2

Być może możesz użyć prognozy jako źródła zasobów i przejść do bardziej szczegółowych usług za pomocą xlink.

Answer 3

byłoby możliwe, aby zrobić coś takiego, skoro mają tak wiele parametrów, więc myślałem, czy jakoś można odnosić go do mieszanki id/parametru combo, aby zmniejszyć rozmiar URL

/WeatherForeCastService// dzień/godzina

Answer 4

www.weatherornot.com/today/days/x  // (where x is number of days) 
www.weatherornot.com/today/9am/hours/h // (where h is number of hours) 

Answer 5

po pierwsze, nie ma po-i-dla-wszystkich prawidłowa odpowiedź.

Każdy prawidłowy adres URL jest czymś sensownym w wyszukiwaniu, uważając je za odpowiednik formularzy zapytań dla osób szukających danych - może to pomóc w zawężeniu scenariuszy.

Jest to kwestia osobistego gustu i ewentualnie zestawu narzędzi, którego używasz, co do podstawowej ścieżki URL i jakie parametry są kodowane. Debata jest trochę jak debata XML nad wprowadzaniem wartości w elementach vs atrybutach. Nie zawsze jest to kwestia racjonalna lub logicznie rozstrzygnięta, ani też nie będzie uprzejmy w swoich komentarzach do twoich decyzji.

Jeśli używasz backendu, takiego jak Rails, oznacza to pewne conventions. Nawet jeśli nie używasz Railsów, rozsądnie jest pracować w ten sam sposób, chyba że masz silny powód do zmiany.W ten sposób ludzie piszący klientom rozmawiać z usług opartych Szyny znajdzie ciebie łatwiejsze do zrozumienia i oszczędza na czas dokumentacji ;-)