У меня немного смущение по поводу темы, поэтому я подумал, что задам вопрос по этому поводу.В настоящее время RESTful design пытается получить гораздо больше места в мире, и люди действительно привыкли к парадигме и неписаным правилам, таким как HTTP-глаголы, ресурсы и т. Д. Я просто хочу ясно видеть это.
Я читалНесколько книг по этой теме, становится понятно, но для сложных случаев использования может потребоваться больше времени для планирования и разработки.Кирстен Хантерс - Irrestible API-интерфейсы, на мой взгляд, являются хорошими, и в этой книге говорится, что у каждого API есть свои сценарии использования, поэтому в последние несколько недель я пытался смоделировать свой API-интерфейс вокруг вариантов использования, но есть некоторые вопросы, на которые я хотел бы ответитьЯ хотел бы показать и, надеюсь, я бы получил несколько интересных идей и советов о том, как продолжать работу в будущем.
Существует система, называемая Федерацией Домов, область очень проста и понятна, отношения также существуют.В этом небольшом приложении вы можете сохранить до 3 разных объектов на 3 разных экранах.
На одном экране вы можете перечислить и забрать дома, с некоторой информацией.На другой вы можете перечислить и забрать жителей, которые будут сдавать в аренду дома.И на третьем вы можете перечислить и забрать аренду, аренда будет содержать информацию об арендованном доме и арендаторе.
Домены следующие:
Дом: введите изображениеописание здесь
Резидент (Арендатор): введите описание изображения здесь
Аренда: введите описание изображения здесь
Как вы можете видеть, домены не так уж и сложны, поистине удивительно, что дом и резидентные сущности изменчивы, а аренда неизменна.Что это значит?Они не объединяются с помощью внешних ключей в базе данных, после того, как вы вставите новый лизинг в базу данных, и если вы измените улицу дома или номер улицы (как это может случиться), таблица аренды всегда будет содержать ранее вставленные данные, поэтому она всегдадублируется и т. д.
Сначала я упомянул, что есть 3 экрана (x2), экран списка и подробный экран.В списке домов вы можете перечислить дома из базы данных.Для данного данного варианта использования мы используем эту конечную точку POST / Houses / query - мы используем слово запроса в качестве ресурса, потому что мы проверяем входящий запрос, который запрашивает дома, он содержит поля об условиях WHERE в SQL и разбивке на страницы и т. Д. Мыиспользуйте конечную точку POST / Houses для создания новой.
Мы используем запрос POST /резиденты / для запросов жителей и POST / резидентов для создания новых жителей.
Мы используем POST / аренды/ query для запроса аренды и POST / аренды для создания новой аренды.
слово запроса может уничтожить правила RESTful, но это слово можно использовать как существительное, поэтому мы все еще здесь: D
Таким образом, варианты использования - это как раз то, что нужно знать, перечислять (запрашивать) и создавать.Так просто (если вы хотите пожаловаться на листинг на основе POST, подумайте об этом, когда мы создаем ресурс для запросов на серверной части, а ответ представляет собой список моделей на основе входящих критериев).
Итак, послеЯ мог бы просто объяснить свои модели, варианты использования и цель моего небольшого приложения, вот мой вопрос.
На экране сведений об аренде, где я могу вставить новые договоры аренды с данными о доме и жителе, появитсябыть утилитой, это будет поле автозаполнения, которое сможет запрашивать модель дома и резидента.
Моя проблема в том, что я смогу использовать уже упомянутые конечные точки / дом / запрос или / резидент/ query - но эти конечные точки будут генерировать меньше данных, я имею в виду, что на экране списка я бы не возвращал все заданные поля из данного домена (возможно, я бы пропустил пол от резидента), и были бы включены только 2-3 столбца.Но на экране вставки мне потребуются все данные для нового объекта аренды.
Мой вопрос заключается в том, как отделить эти модели друг от друга в случаях использования?Как мне назвать мои ресурсы / конечные точки?Я думал назвать конечные точки, которые будут использоваться функцией автозаполнения, следующим образом:
POST / Houses / query / lease -> слово аренды показало бы, что этобудет использоваться с экрана аренды функцией автозаполнения или POST / Houses / Request / Autocomple
POST / Resorts / query / lease -> слово аренды будет означать, что это происходитдля использования с экрана аренды функцией автозаполнения или POST /резиденты / запросы / автозаполнения
Пока я углубляюсь в тему, чем больше тема растет, тем большеЯ все больше путаюсь после того, как узнаю больше об этом, некоторые люди говорят, что некоторые говорят другие вещи.
Я хотел бы видеть ясность, но иногда я не знаю, какой путь правильный.Я пытаюсь смоделировать свои API-модели вокруг вариантов использования и стараюсь не связывать их с реальными объектами в базе данных.
Любые ответы и советы приветствуются, я хочу ясно видеть тему :)