Какую архитектуру можно использовать, если местоположение веб-службы постоянно меняется

Вы можете думать о веб-сервисе как об интерфейсе или API. Вы клиент этого интерфейса, API. Если интерфейс меняет вас как клиента, необходимо адаптировать ваш вызов. Нет хорошего способа справиться с этим. Обычно те, кто предоставляют API, должны поддерживать его стабильность и предлагать способы перехода на более новые версии и так далее. Но я полагаю, что вы не можете запросить это у службы погоды, о которой идет речь. Теперь, чтобы справиться с частой сменой интерфейса, вы можете сделать следующее: - создать свой собственный интерфейс, который определяет данные, которые вы хотите вернуть, это уровень абстракции. - закодируйте свой клиент в соответствии с вашим интерфейсом, к которому у вас есть контроль над изменениями, - осуществите реализацию ваших интерфейсов, запросив метеорологическую службу 1 или метеорологическую службу 2. Это всего лишь отображение данных. Метеослужбы 1 и 2 могут быть совершенно разными службами, или вы можете думать об одной и той же службе с разными версиями. Ни один из ваших клиентских кодов не должен изменяться, только это отображение будет меняться при изменении URL.

Это решение помогает вам легко переключаться между упомянутыми реализациями. То, что я описал, является решением ООП вашей проблемы, поэтому вам нужно будет использовать язык ООП, чтобы иметь полиморфное поведение.

Что касается последнего пункта, который вы можете выбрать, чтобы представить свой сервис (интерфейс, о котором я говорил выше) как сервис REST.

Задача 1) Дело не в архитектуре, а скорее в дизайне сервиса. Основанный на принципах проектирования сервисов и 8 сервисных принципов разработки , этот сценарий в значительной степени нарушает множество определенных практик. Сервисный центр должен быть совместимым и обеспечивать возможность обнаружения сервисов. Способ предоставления услуги должен учитывать сценарий изменения URL-адреса.

Технически это можно решить с помощью DNS, обратного прокси-сервера или простого добавления определенного статического URL-адреса, который может выполнять вызов службы, и перенаправить на нужную операцию службы в терминологии SOAP или ресурс API в терминологии REST.

Он должен быть статическим, как http://example.org/weather.asmx, а weather.asmx будет содержать другие операции, которые могут быть вызваны и изменены динамически, но h ttp://example.org/weather.asmx должен быть постоянным.

Задание 2) Если вам нужно добиться этого с помощью REST, вы должны понимать, как работает HTTP-код и как работать без сохранения состояния. Развивайте свои навыки с помощью бесплатных онлайн-тренингов, например, от udemy.com по разработке API.

Я бы предложил следовать учебному пособию, блогу и видео-учебнику на тему « разработать и внедрить API с помощью учебника JAVA ».