В настоящее время мы разрабатываем некоторые службы данных, которые должны доставлять данные многим отдельным сторонам и поэтому должны быть достаточно общими, чтобы их можно было распространять, но не было сложными для понимания.Как правило, это довольно просто, некоторые, но мы не на том этапе, когда мы обсуждаем возможности для основных данных, которые имеют некоторые иерархии наследования, а также дополнительные данные.Например:
- Индивидуум - это просто физическое лицо (без формирования)
- Физическое лицо - это сотрудник
- Физическое лицо - это участник мероприятия
- и т. Д.
Кроме того, индивидуальный HAS дополнительные данные
- Адреса
- Номера телефонов
- и т. Д.
Просмотрнесколько документов REST Best Practices, например https://pages.apigee.com/rs/apigee/images/api-design-ebook-2012-03.pdf,, наиболее близким к решению, которое я вижу, является создание конечных точек для каждого унаследованного типа:
- ServiceApi / DataServices / v1 / Individuals
- ServiceApi / DataServices / v1 / Employees
И, возможно, добавить «Has» -данные с механизмом частичного ответа.Это кажется странным, поскольку теперь потребитель должен знать, какой подтип он запрашивает.
Другое решение может заключаться в добавлении множества конечных точек и создании DTO для каждой запрашиваемой возможности:
- IndividualWithAddresses
- IndividualWithPhoneNumbers
- EmployeeWithPhoneNumbers
Ни одно из этих решений, ни другие, которые мы нашли, не кажется привлекательным.Я чувствую, что крупные провайдеры API, которые, безусловно, имеют более богатую модель данных, должны были проводить подобные обсуждения.Есть ли решение, позволяющее контролировать сложность и при этом оставаться достаточно гибким?