Орхан Гасанлы

Advanced Custom Fields
WPML

Имея ссылку такого типа вы можете вызывать у объекта методы Object, такие как toString или hashCode.

Так что формально да, наследуется.

Как минимум это позволяет хранить такие ссылки в коллекциях.

Вот вы на Тостер заходите, вопросы создаёте, просматриваете, сайт обновляется, появляются новые фичи, а приходилось ли вам обновлять ваш клиент (браузер) чтобы новыми фичами пользоваться?
Мне не приходилось, нужно лишь страничку обновить, и получить обновленный гипертекст с новыми возможностями для переходов состояния.
Вот вам и HATEOAS, используется часто. Профит - расширяемость, масштабируемость без необходимости обновления клиента.

Благодаря HATEOAS, в частности, мы видим Веб таким, каким он существует сейчас, и с его текущими масштабами.

А если к этому добавить уникальные url'ы, self-descriptive messages, кэширование, не хранить состояние клиента на сервере, использовать известные клиенту и серверу медиа типы можно и REST API получить(есть ещё нюансы)

Вы не правильно вставляете id.
Правильный вариант:

<?php if( have_rows('footer_socials_link', 2) ): ?>
<?php while( have_rows('footer_socials_link', 2) ): the_row(); ?>


<?php endwhile; ?>
<?php endif; ?>

1996 - 2019 = -23

Cloud Foundry - это PaaS, такая же как Heroku. Вам не надо настраивать сервера, на которых будет работать ваше приложение, не надо заботиться об отказоустойчивости или масштабировании с ростом нагрузки. Просто "нажал кнопку" и твоё приложение работает где-то там в облаке.

P.S. Если читаете "Java в облаке" Лонга и Бастани, то лучше не тратьте время. Это рекламный буклет Pivotal, а не учебник.

Интерфейсы: BooksRepository и UserRepository
Классы: BooksRepositoryImpl и UserRepositoryImpl

Есть две основные причины появления "прозрачного сервисного слоя" в приложениях:

1. Потому что так принято. Автор делает примитивное приложение, которому вообще не нужна многослойная архитектура, но умные дяди говорят, что слои быть должны, и он вкорячивает слои ритуальные.
   
2. На вырост. В MVP в сервисный слой положить нечего, но развитая бизнес-логика предвидится в следующих версиях. Намного легче сделать пустой слой, а потом постепенно его наполнять, чем добавлять его потом в рабочий код.
   

Просто распаковываете архив в удобное для вас место, устанавливаете переменную окружения JAVA_HOME, указывающую на это место, и добавляете "%JAVA_HOME%\bin" в переменную окружения PATH.

Что мешает создавать их по мере необходимости? Более того, можно вообще сделать один убер-контроллер, который будет отвечать на всё, но никогда не делайте так :)

Контроллеры надо разделять по области их деятельности, по той проблеме, которую они решают. Он может отдавать не только же страницы, но и json'ы какие-нибудь - у вас же на странице может быть динамическое содержимое, которое нужно получать без перезагрузки всей страницы. А вдруг оно нужно ещё и на другой странице? Например список пользователей. У нас есть страница для отображения списка пользователей и мы в котроллере пользователей отдаём эту страницу, но где-то на другой странице тоже нужно отобразить список пользователей или вообще отдать просто через REST другой системе, логично метод, возвращающий json-списка пользователей разместить в этом же контроллере.

Другой путь поделить ваши контроллеры на котроллеры, которые отдают страницы и контроллеры, которые отдают json. Это, можно сказать, вкусовщина.

Вы делать начните, а там поймёте, как вам удобнее. Не надо бросаться делать сразу все контроллеры, делайте постепенно по областям все слои, потом переходите на другую область. Можно возвращаться же и править что-то. Разбейте задачу на подзадачи (декомпозируйте) по фичам вашего приложения и пилите фичами.

А если вы работаете в паре с фронтендером, то обязательно обудите с ним, какие ему нужны API и данные на клиенте - это также поможет вам решить ваши вопросы с контроллерами.