Что такое RESTful-ресурс в контексте больших наборов данных, т.е. данные о погоде?

Question

Итак, я работаю над веб-сервисом, чтобы получить доступ к нашим данным прогноза погоды (10000 местоположений, по 40 параметров каждый, почасовые значения в течение следующих 14 дней = около 130 миллионов значений).

Итак, я прочитал все о службах RESTful и его идеологии.

Так что я понимаю, что URL-адрес адресован ressource.

Но что a ressource в моем случае?

Общий пример использования заключается в том, что вы хотите получить данные по нескольким параметрам за один раз в одном или нескольких местах. Таким образом, ясно, что каждая ценность его собственного URL-адреса не является прайтическим и приведет к сотням запросов. У меня такое ощущение, что моя конкретная проблема не вписывается в шаблон RESTful.

Обновление: Чтобы уточнить: Существуют два шаблона использования услуги. 1. Сырьевые данные; строк и строк данных для нескольких местоположений и параметров.

2. Интерпретированные данные; исходные данные, рассчитанные на символы (например, Солнца &) и другие параметры.

Существует не один «прогноз». У разных клиентов разные потребности в данных.

Причина, по которой я думаю, что это не вписывается в шаблон REST, заключается в том, что, хотя у меня действительно есть источник прогноза, мне все равно придется отправлять множество параметров запроса. Таким образом, простой GET-запрос на ressource не работает, я в конечном итоге получаю данные POSTing по всему месту.

Answer 1

Так я работаю на веб-сервиса, чтобы получить доступ к нашим данным прогноза погоды (10000 местоположения, 40 параметров каждый, ежечасные значения в течение следующих 14 дней = около 130 миллионов значений). ... Но что такое реферат в моем случае?

Это зависит от деталей вашего проблемного домена. Простое наличие большого количества данных не является хорошей причиной для предотвращения REST. Существуют интеллектуальные способы и немые способы моделирования и публикации этих данных.

Как вы правильно поняли, ваша главная цель на этом этапе должна состоять в том, чтобы понять, что такое ресурс. Зная только достаточно о прогнозе погоды, чтобы следить за Погодным каналом, я не буду здесь очень помогать. Для таких экспертов домена, как вы, вы можете сделать этот звонок.

Если вы хотите объяснить в деталях основные концепции доменов, с которыми вы работаете, это может сделать немного проще дать конкретные советы.

Например, одним ресурсом может быть Прогноз. Когда погоди говорят о Прогнозах, какие слова продолжают подниматься? Когда вы думаете о том, чтобы разбить прогноз на более мелкие элементы, какие слова вы используете для описания фигур?

Сделайте этот процесс рекурсивно, и вы, вероятно, сможете составить список важных терминов. Не забывайте, что эти термины могут описывать вещи или действия. Подумайте, что означают эти термины, какие данные вы можете использовать для их моделирования, как их можно агрегировать.

На этом этапе у вас появятся цели, из которых вы можете начать создавать систему RESTful, но не раньше.

Не забывайте, что система RESTful не является дампом данных, завернутым в HTTP - это система hypertext-driven.

Также не забывайте, что media types являются точкой соприкосновения вашего сервера и его клиентов. Тип мультимедиа ограничен только вашим воображением и может моделировать наборы данных любого размера, если вы умны в этом. Он может содержать XML, JSON, YAML, двоичные элементы, такие как Bloom Filter, или все, что работает для проблемы.

Answer 2

Возможно, вы можете использовать прогноз как источник и углубиться в мелкозернистые службы с помощью xlink.

Answer 3

Можно ли сделать что-то вроде этого, так как у вас так много параметров, так что я думаю, если каким-то образом вы можете связать его с соединением идентификатор/параметра комбо, чтобы уменьшить размер URL-адрес

/WeatherForeCastService// день/час

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

Во-первых, нет раз и для всех, правильный ответ.

Каждый действительный URL-адрес имеет смысл запросить, подумать о них как об эквиваленте для предоставления форм запросов для людей, ищущих ваши данные, что может помочь вам сузить сценарии.

Это вопрос личного вкуса и, возможно, инструментарий, который вы используете, относительно того, что входит в основной путь URL и какие параметры кодируются. Дискуссия немного напоминает дискуссию XML по поводу размещения ценностей в элементах и ​​атрибутах. Это не всегда рациональный или логически решаемый вопрос, и никто не будет относиться к их комментариям к вашим решениям.

Если вы используете бэкэнд как Rails, это подразумевает определенный conventions. Даже если вы не используете Rails, имеет смысл работать одинаково, если у вас нет веских причин для изменения.Таким образом, люди, пишущие клиентов говорить с услугами Rails на основе будет найти ваш легче понять и это избавит вас от времени документации ;-)