REST возвращая граф объектов
i + 2 это выражение, вы должны присвоить результат где-нибудь, поэтому правильный синтаксис:
for(int i = 0; i < numbers.length; i=i+2)
{
numbers[i] = 2;
System.out.println(numbers[i]);
}
3 ответа
Сделайте плоскую Вселенную, которую Вы выставляете миру.
Даже когда я использую SOAP, который может легко обработать иерархические графы объектов до любой глубины, я сглаживаю график и связываю все с простыми идентификаторами (Вы могли даже использовать свою базу данных ID, хотя идея состоит в том, что Вы хотите Вас, не хотят выставлять Ваш PKs миру).
Ваша объектная вселенная в Вашем приложении - не обязательно тот же, Вы выставляете миру. Позвольте A иметь детей и позволить B иметь детей, но нет никакой потребности отразить, что в остальных запрашивают URL.
Почему сглаживаются? Поскольку затем можно сделать, вещам нравится, выбирают объекты позже идентификатором или отправляют их в пакетах (оба тот же случай, более или менее)... И лучше, чем все это, запрос URIs не изменяются, когда иерархия объектов изменяется (возразите 37252, всегда то же, даже когда это было повторно классифицировано).
Править: Ну, Вы попросили его... Вот архитектура, которую я закончил тем, что использовал: пакет: сервер - содержит суперклассы, которые совместно используются сервером фронтенда и сервером бэкэнда
пакет: frontEndServer - содержит Интерфейс сервера, которого должен придерживаться сервер фронтенда. Интерфейс хорош, потому что, если Вы решаете измениться от SOAP до прямого Веб-клиента (который использует JSON или что бы то ни было, также), у Вас есть интерфейс все размеченные. Это также содержит все реализации для frontEnd классов, которые будут брошены клиенту и всей логике для взаимодействия между классами кроме того, как говорить с клиентом.
пакет: backEndServer - содержит Интерфейс сервера, которого будет придерживаться сервер бэкэнда. Примером реализации Сервера был бы тот, который говорит с MySql DB или тем, который говорит с DB XML, но Интерфейс сервера нейтрален. Этот пакет также содержит все классы что реализации использования Интерфейса сервера для получения работы, сделанной, и вся логика для бэкенда за исключением персистентности.
затем у Вас есть пакеты реализации для каждого из них..., которые включают материал как то, как сохраниться для бэкенда и как говорить с клиентом для фронтэнда. Пакет реализации фронтенда мог бы знать, например, что пользователь вошел в систему, тогда как frontEndServer просто знает, что должен реализовать методы для создания пользователей и входа в систему.
С начала описать это я понимаю, что это требовало бы времени больше для описания всего, но здесь у Вас есть суть его.
Нет ничего, говоря, что Ваш интерфейс REST не может быть реляционным.
- /bookstore/{BookstoreID}
- /bookstore/Книги {bookstoreID} /
- /book/{BookID}
В основном Вы имеете 1:1 корреспонденция Вашей схеме DB.
За исключением отношений Many-Many, формирующих дочерние списки. Например,/bookstore/657/books должен возвратить список книжных идентификаторов или URL. Затем, если Вы хотите данные определенной книги, можно вызвать 3-й URL.
Это просто первое, что пришло на ум, обсудите достоинства.
Один существенный УСПОКОИТЕЛЬНЫЙ принцип - то, что все имеет URI.
У Вас есть URI как это.
- /A/и/A/id/для получения списка A и определенного A. Ответ включает идентификатор B.
- /B/и/B/id/для получения списка B и определенного B. Ответ B включает идентификатор C.
- /C/и/C/id/для получения списка C и определенного C.
Через серию запросов, можно восстановить структуру ABC. Вы получаете A, затем получаете соответствующий B. При получении B Вы получаете различные C, на которые ссылаются.
Править
Ничто не препятствует тому, чтобы Вы возвратились больше.
Например, у Вас могли бы быть следующие виды URI.
/flat/A/id/,/flat/B/id/и/flat/C/id/возвратиться "плоский" (т.е. никакая глубина) структуры./deep/A/id/,/deep/B/id/и/deep/C/id/возвратить структуры с полной глубиной.
/deep/A/id/ была бы вся структура, в большом, вложенном XML-документе. Прекрасный для клиентов, которые могут обработать его. /flat/A/id/ был бы просто верхний уровень в плоском документе. Лучше всего для клиентов, которые не могут обработать глубину.