Как обрабатывать сложную доступность информации в ООП из RESTful API

Question

Моя проблема в том, что я имею дело с RESTful API, который возвращает информацию об объектах, и при написании классов для их представления я не уверен, как лучше всего обрабатывать все возможности состояния доступности каждой переменной. Из того, что я могу сказать, есть 5 возможностей: информация

• доступно
• не было запрошено
• в данный момент запрашивается (асинхронно)
• недоступно
• не применимо

Таким образом, наличие объекта, представляющего свои данные со значением или нулем, не обрезает их. Чтобы привести более конкретный пример, я работаю с API для Конгресса США, поэтому проблема выглядит следующим образом:

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

Я вижу несколько вариантов:

• Я могу создать объект Legislator и заполнить его информацией, которая у меня есть, но затем мне нужен механизм отслеживания доступности информации с помощью методов получения и установки. Это то, что я сейчас делаю, но это требует много повторного кода.

• Я мог бы создать отдельный класс для сокращенных объектов и заменить их, когда получу больше, неизменными "завершенными" объектами, но тогда я должен быть очень осторожным при замене всех ссылок на них и также просмотрите несколько обручей для недоступной и особенно неприменимой информации.

Итак, мне просто интересно, что другие люди воспринимают по этому вопросу. Есть ли другие (лучшие?) Способы справиться с этой сложностью? Каковы преимущества и недостатки разных подходов? Что я должен учитывать при выборе подхода?

[Примечание: я работаю в Objective-C, но это не обязательно относится к этому языку.]

Answer 1

Если вы хотите рассматривать эти удаленные ресурсы как объекты на стороне клиента, сделайте себе огромное одолжение и забудьте про модное слово REST. Вы сведете с ума. Просто примите, что вы выполняете HTTP RPC, и продолжайте, как если бы вы делали любой другой проект RPC.

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

Что я знаю, так это то, что если вы пытаетесь использовать «REST API» для извлечения объектов по проводам, вы придете к выводу, что REST - это загрузка дерьма .

Answer 2

Это интересный вопрос, но я думаю, что вы, вероятно, немного обдумали это.

Во-первых, я думаю, что вы слишком много рассматриваете возможные состояния информации;рассмотрите более основополагающее соображение, что у вас либо есть информация, либо ее нет.ПОЧЕМУ у вас есть информация, на самом деле не имеет значения, за исключением одного случая.Позволь мне объяснить;если информация о конкретном законопроекте или законодателе или чем-либо еще не применима, вы не должны запрашивать ее / нуждаться в ней.Это «государство» не имеет значения.Точно так же, если информация находится в процессе запроса, она просто еще не доступна;единственное состояние, которое вас действительно волнует, это то, есть ли у вас информация или если у вас ее еще нет.

Если вы начнете беспокоиться о дальнейшей глубине процесса запроса, вы рискуете попасть в глубокий, бесконечный циклуправления государством;изменилась ли информация между тем, как я ее получил, и сейчас?Все, что вы можете знать об информации, это если вам сказали, что это такое.Это фундаментально для процесса REST;вы получаете ПРЕДСТАВЛЕНИЕ основных данных, но в этом нет ошибки;представление НЕ является базовыми данными, не больше, чем имя конгрессмена - сам конгрессмен.

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

Наконец, реальный ключ здесь заключается в том, что вам нужно помнить, что структура RESTful управляется гипермедиа;запрос к объекту, который не возвращает полные данные объекта, должен возвращать URI для запроса данных подобъекта;и так далее.Ключевым моментом здесь является то, что эти структуры не являются статичными, как будто ваша объектная структура, похоже, надеется их обработать;они динамические, и это зависит от сервера, чтобы определить представление (то есть, взаимосвязь).Попытка определить это в камне с конкретным представлением объекта заблаговременно означает, что вы имеете дело с системой таким образом, что REST никогда не предназначался.