Какова лучшая практика в определении сервиса мыла (универсальный по сравнению с определенной операцией)?
stdout вспыхивает на новых строках. Поскольку ваш оператор print! не содержит и не заканчивается новой строкой, он не будет сброшен. Вам нужно сделать это вручную, используя std::io::stdout().flush()
Например
use std::io::{self, Write};
fn main() {
let mut input = String::new();
print!("Enter a string >> ");
let _ = io::stdout().flush();
io::stdin().read_line(&mut input).expect("Error reading from STDIN");
}
2 ответа
По-видимому, Вы пишете протокольный уровень, который поймет Ваши различные типы сообщений. Вам также будет нужен прикладной уровень для парсинга содержания сообщения. Разные подходы, которые Вы упоминаете, сместят нагрузку парсинга между этими двумя слоями. Так, например:
Решение A: протокольный уровень делает весь парсинг и возвращает данные и команду. Прикладной уровень может просто использовать данные. Это также известно как шаблон RPC.
Профессионалы: можно проверить сообщения. Можно отобразить сообщения непосредственно на вызовы приложения.
Недостатки: Если необходимо внести изменение в интерфейс, изменения протокола.
Решение B: протокольный уровень возвращает два значения и команду. Прикладной уровень должен использовать команду для парсинга значений в типы.
Профессионалы: протокол никогда не изменяется.
Недостатки: Вы не можете проверить сообщения. Ваш код приложения более сложен.
Решение C: протокольный уровень возвращает два известных типа и команду, которая должна быть проанализирована. Прикладной уровень может просто проанализировать команду и использовать данные.
Профессионалы: Я не могу думать ни о ком, походит не на очень хороший компромисс.
Недостатки: Оставляет парсинг только частично сделанным.
Решение D: протокольный уровень возвращает известные типы (способ, которым Вы реализовали его), и групповая команда. Прикладной уровень должен посмотреть на данные, которые он получает, и преобразуйте групповую команду в определенную команду. Это подобно остальным архитектура.
Профессионалы: Вызовы являются отличными операциями так, чтобы Вы могли, например, кэшироваться, получают ответы.
Недостатки: Сложность на прикладном уровне
Модель The REST обычно реализуется по-другому, чем Вы обрисовали в общих чертах. Это использует HTTP, ПОЛУЧАЮТ, POST, ПОМЕЩАЮТ, УДАЛЯЮТ сообщения для передачи произвольных документов. Параметры даны как часть URL. Так, например:
<insert airport="JFK" city="New York" country="USA" continent="North America" />
становится
<insert URL="airport?city=Chicago">ORD</insert>
Или если Вы используете HTTP, это становится запросом POST в аэропорт URL с параметрическим усилителем города с содержанием, являющимся информацией об аэропорте. Обратите внимание, что часть этого становится более ясной с большим количеством compliated данных, где у Вас есть несколько элементов и смешанных типов. Например, если Вы хотели отправить сокращение аэропорта, длинное имя и высоту.
Я думаю остальные, архитектура могла работать вполне хорошо на интерфейс, который Вы описываете. Пока все, что необходимо сделать, поддерживать операции CRUD. Многих сайтов, которые дадут Вам за и против остальных архитектурный стиль.
Лично я предпочитаю стиль RPC (Решение A) с некоторыми УСПОКОИТЕЛЬНЫМИ атрибутами. Я хочу, чтобы протокол сделал, парсинг работает и проверяет сообщения. Это обычно, как люди реализуют интерфейсы веб-сервиса SOAP.
Ваш интерфейс может выглядеть простым сегодня, но завтра один из Ваших клиентов собирается попросить у Вас нового вызова, который не соответствует остальным модель так хорошо, и Вы втиснете его в существующие четыре сообщения.
Это старый вопрос, и я уверен, что служба была написана давно, но я все равно хотел дать ответ.
Подход RESTful заключается в определении ресурса аэропорта, например этого:
<airport href="/airports/JFK">
<name>JFK</name>
<city>New York</city>
<country>USA</country>
<continent>North America</continent>
</airport>
Или, если вы хотите использовать совместимый с браузером микроформат:
<div class="object airport" href="/airports/JFK">
<ul class="attributes">
<li class="name">JFK</li>
<li class="city">New York</li>
<li class="country">USA</li>
<li class="continent">North America</li>
</ul>
</div>
Этот ресурс будет расположен по URI, например / airport / JFK , который будет извлекаться методом GET , обновляться методом PUT и удаляться методом DELETE .
В подобном дизайне URI / airport / будет представлять ресурс контейнера для всех аэропортов в базе данных, а такие URI, как / airport /? City = New + York и / airport /? Country = USA будут фильтрами в контейнере, чтобы возвращать подмножество аэропортов. Оба они будут методами GET , а ресурсы будут содержать список ресурсов аэропорта, как определено выше, либо полностью (поскольку они маленькие), либо с несколькими полезными атрибутами и href , указывающий на полный ресурс для каждого аэропорта.
Наконец, добавление нового ресурса может быть методом PUT для полного URI аэропорта или методом POST в / airport / .В обоих случаях тело запроса - это ресурс аэропорта, как показано выше. Разница между методами заключается в том, кто определяет окончательный URI для аэропорта: клиент принимает решение о PUT , а служба принимает решение о POST . Какой из них вы будете использовать, зависит от того, могут ли ваши клиенты разумно определить правильный URI. Обычно решение принимает служба, потому что URI содержат уникальный числовой идентификатор, и служба должна его выбрать.
Конечно, ваш первоначальный вопрос касался SOAP, а не REST. Я бы пошел дальше и настроил дизайн RESTful, как я описал, а затем описал свои ресурсы как сложные типы с использованием XSD и службы SOAP с действиями, которые дублируют GET , PUT , Операции DELETE и POST службы RESTful. Это даст вам эквивалент RPC:
class Airport
has String name
has String city
has String country
has String continent
method void update(name, city, country, continent)
method void delete()
class AirportList
method Airport[] get(opt name, opt city, opt country, opt continent)
method void add(name, city, country, continent)