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

Question

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

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

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

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

Там есть пара опций, которые я вижу:

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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