REST - сложные приложения

«Фильтр как ресурс "- идеальный такт для этого.

Вы можете ПОЛУЧИТЬ определение фильтра в ресурс фильтра, и он может вернуть идентификатор фильтра.

PUT является идемпотентным, поэтому даже если фильтр уже существует, вам просто нужно обнаруживают, что вы видели фильтр раньше, чтобы вы могли вернуть правильный идентификатор для фильтра.

Затем вы можете добавить параметр фильтра к другим вашим запросам, и они смогут захватить фильтр для использования в запросах.

GET / medications? Filter = 1234 & page = 4 & pagesize = 20

Я бы пропустил необработанные фильтры через какой-то процесс канонизации, просто чтобы иметь нормализованный набор, чтобы, например, фильтр «firstname = Bob lastname = Eubanks» был идентичен фильтру «lastname = Eubanks firstname = Bob». Но это только я.

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

Изменить ответ на вопрос ...

Начнем с основ.

Просто вы хотите указать фильтр для использования в запросах, но эти фильтры (потенциально) сложны и сложны. Если бы это было просто / medications / 1234, это не было бы проблемой.

Фактически, вам всегда нужно отправлять фильтр на запрос. Вопрос в том, как представить этот фильтр.

Основная проблема с такими вещами, как сеансы в системах REST, заключается в том, что они ' re обычно управляется «вне группы». Когда вы, скажем, идете и создаете лекарство, вы ВСТАВЛЯЕТЕ или ОТПРАВЛЯЕТЕ на ресурс лекарств, и вы получаете ссылку на это лекарство.

Во время сеанса вы (обычно) получаете обратно файл cookie или, возможно, какой-то другой токен для представления этого сеанса. Если ваш запрос PUT к ресурсу лекарств также создал сеанс, то, по правде говоря, ваш запрос создал два ресурса: лекарство и сеанс.

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

Итак, если я выполняю GET для ресурса с именем / medications / search, и файл cookie представляет сеанс, и в этом сеансе есть фильтр. , вы можете увидеть, как на самом деле это имя ресурса, / medications / search, на самом деле бесполезно. У меня нет всей информации, необходимой для эффективного использования, из-за побочного эффекта файла cookie, сеанса и фильтра в нем.

Теперь вы могли бы переписать имя: / medications / search? Session = ABC123, эффективно встраивая cookie в имя ресурса.

Но теперь вы сталкиваетесь с типичным контрактом сеансов, особенно с тем, что они недолговечны. Итак, названный ресурс менее полезен, долгосрочен, не бесполезен, просто менее полезен. Прямо сейчас этот запрос дает мне интересные данные. Завтра? Возможно нет. Я получаю неприятную ошибку о том, что сеанс пропал.

Другая проблема заключается в том, что сеансы обычно не управляются как ресурс. Например, это обычно побочный эффект, vs явно управляется через GET / PUT / DELETE. Сеансы также являются «кучей мусора» состояния веб-приложения. В этом случае мы просто надеемся, что сеанс правильно заполнен тем, что необходимо для этого запроса. На самом деле мы не знаем. Опять же, это побочный эффект.

А теперь давайте немного перевернем его с ног на голову. Давайте использовать /medications/search?filter=ABC123.[12131 sizes Очевидно, случайно, это выглядит идентично. Мы просто изменили название с «сеанс» на «фильтр». Но, как уже говорилось, фильтры в данном случае ЯВЛЯЮТСЯ «первоклассным ресурсом». Их нужно создавать, управлять и т. Д. Так же, как лекарство, JPEG или любой другой ресурс в вашей системе. Это ключевое различие.

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

Итак, вы можете видеть, как на высоте 30 000 футов не так много разница в случае между фильтром и сеансом. Но когда вы увеличиваете масштаб, они совсем другие.

С помощью ресурса фильтра вы можете сделать их постоянными навсегда. Вы можете истечь их срок, вы можете делать все, что хотите. Сессии, как правило, имеют заранее заданную семантику: короткое время, продолжительность соединения и т. Д. Фильтры могут иметь любую семантику. Они полностью отделены от того, что идет с сеансом.

Если бы я делал это, как бы я работал с фильтрами?

Я бы предположил, что меня действительно не волнует содержимое фильтра. В частности, я сомневаюсь, что когда-либо буду запрашивать «все фильтры, выполняющие поиск по имени». На данном этапе это кажется неинтересной информацией, поэтому я не буду строить вокруг нее.

Затем я бы нормализовал фильтры, как я упоминал выше. Убедитесь, что эквивалентные фильтры действительно эквивалентны. Вы можете сделать это, отсортировав выражения, убедившись, что имена полей все в верхнем регистре или что-то еще.

Затем я бы сохранил фильтр в виде документа XML или JSON, в зависимости от того, что более удобно / подходит для приложения. Я бы дал каждому фильтру уникальный ключ (естественно), но я бы также сохранил хэш для фактического документа с фильтром.

Я бы сделал это, чтобы иметь возможность быстро определить, сохранен ли уже фильтр. Поскольку я нормализую его, я «знаю», что XML (скажем) для логически эквивалентных фильтров будет идентичным. Итак, когда кто-то переходит к PUT или вставляет новый фильтр, я бы проверил хэш, чтобы узнать, хранился ли он раньше. Я вполне могу вернуть более одного (конечно, хэши могут конфликтовать), поэтому мне нужно будет проверить фактические полезные данные XML, чтобы увидеть, совпадают ли они.

Если фильтры совпадают, я возвращаю ссылку на существующий фильтр . Если нет, я бы создал новый и вернул его.

Я также не разрешил бы фильтр UPDATE / POST. Поскольку я раздаю ссылки на эти фильтры, я бы сделал их неизменяемыми, чтобы ссылки оставались действительными. Если бы мне нужен был фильтр по «роли», скажем, «получить все препараты с истекшим сроком годности», я бы создал ресурс «именованный фильтр», который связывает имя с экземпляром фильтра, чтобы фактические данные фильтра могли изменяться, но имя остается прежним.

Помните также, что во время создания вы находитесь в состоянии гонки (два запроса пытаются создать один и тот же фильтр), поэтому вам придется это учитывать. Если ваша система имеет большой объем фильтра, это может быть потенциальным узким местом.

Надеюсь, это проясняет проблему для вас.

re находится в состоянии гонки (два запроса пытаются создать один и тот же фильтр), поэтому вам придется это учитывать. Если ваша система имеет большой объем фильтра, это может быть потенциальным узким местом.

Надеюсь, это проясняет проблему для вас.

re находится в состоянии гонки (два запроса пытаются создать один и тот же фильтр), поэтому вам придется это учитывать. Если ваша система имеет большой объем фильтра, это может быть потенциальным узким местом.

Надеюсь, это проясняет проблему для вас.