Каково преимущество использования REST вместо не-REST HTTP?

Я рекомендую взглянуть на книгу Райана Томайко Как я объяснил свою жену "REST"

Третья сторона редактирует

Выдержка из путевой ссылки:

Как насчет примера. Вы учитель и хотите управлять учениками:

• в каких классах они учатся,
• какие оценки они получают,
• контакты для экстренных случаев,
• информация о книгах, из которых вы преподаете, и т.д.

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

Каждая из систем могла бы получать информацию друг от друга с помощью простого HTTP GET. Если одной системе нужно что-то добавить в другую, она будет использовать HTTP POST. Если система хочет обновить что-то в другой системе, она использует HTTP PUT. Единственное, что осталось выяснить - как должны выглядеть данные.

Не следует переносить элементы/теги блоков (например, < div > ) в встроенные тэги (например, < a > ). Это требует неприятностей.

Именно так работают enums в .NET. Перечисление не является ограничительным набором значений, это действительно просто набор имен для чисел (и тип, чтобы собрать эти имена вместе) - и я согласен, что иногда это боль.

Если необходимо проверить, действительно ли значение определено в перечислении, можно использовать Enum.IsDefined после анализа. Если вы хотите сделать это более безопасным способом, вы можете посмотреть на мой проект Unconstrained Melody , который содержит множество ограниченных общих методов.

Проще говоря, REST означает использование HTTP таким, каким он должен быть.

Посмотрите на диссертацию Роя Филдинга об REST . Я думаю, что каждый человек, который занимается веб-разработкой, должен его прочитать.

Следует отметить, что Рой Филдинг также является одним из ключевых драйверов протокола HTTP.

Чтобы назвать некоторые из дополнений:

• Просто.
• Можно использовать кэш HTTP и прокси-сервер, чтобы справиться с высокой нагрузкой.
• Это помогает организовать даже очень сложное приложение в простые ресурсы.
• Новые клиенты могут легко использовать ваше приложение, даже если вы не разработали его специально для них (вероятно, потому, что их не было рядом при создании приложения).

Поисковые системы могут игнорировать строки запроса.

Я обнаружил, что наилучшим способом решения этой проблемы является не прямое использование потоков, а использование рамки Исполнителя. Вы можете поэкспериментировать с различными конфигурациями, но я обнаружил, что мне нравится callerCharingPolicy.

Я думаю, что одним из наиболее важных первых шагов является установка стандартов. Установка обязательного стиля кодирования (без однострочного кода if/for/while/etc. инструкции, вкладки вместо мест, документы по каждой функции и т.д.); наличие минимального требования к чистоте кода очень важно для поддержания высокого уровня контроля качества.

Следующий хороший шаг - найти, где ваши сотрудники компетентны, а где нет. Выясните, с какими частями языка у ваших сотрудников возникают проблемы (например, новые функции PHP 5, эффективное использование DOMDocument, запись безопасных классов...) и назначьте обязательное чтение.

Это подводит меня прямо к моему следующему предложению: иметь «библиотеку компании». Для мест, где я работал, это была книжная полка, из которой сотрудники могут брать книги для справки или учебы. Храните его в запасе с различными книгами от разных издателей. Из того, что я видел, сотрудники более чем готовы узнать что-то новое, если это не вынуждено к ним и они в состоянии сделать это на своем досуге. Хороший программист всегда хочет учиться.

Наконец, запустите блог/список рассылки/форум, в котором сотрудникам предлагается регулярно участвовать. Опубликуйте лакомые куски (и предложите своим сотрудникам также опубликовать) о передовых практиках. Вы можете опубликовать информацию о том, как использовать gettype с оператором switch плохо или как правильно отключить волшебные кавычки программно.

Удачи!

• Дайте каждому «ресурсу» идентификатор
• Соедините вещи вместе
• Используйте стандартные методы
• Ресурсы с несколькими представлениями
• Сообщайтесь безгосударственно

Можно сделать все только с помощью POST и GET? Да, это лучший подход? Нет, почему? потому что у нас есть стандартные методы. Если вы подумаете еще раз, можно было бы сделать все, используя просто GET.. так почему мы вообще должны потрудиться использовать POST? Из-за стандартов!

Например, сегодня, думая о модели MVC, вы можете ограничить свое приложение, чтобы отвечать только на определенные виды глаголов, такие как POST, GET, PUT и DELETE. Даже если под капотом все эмулировано на POST и GET, не имеет смысла иметь разные глаголы для разных действий?

ИМХО, самое большое преимущество, которое дает REST, заключается в уменьшении связи между клиентом и сервером. Гораздо проще развить интерфейс REST с течением времени, не нарушая работу существующих клиентов.

Кэширование.

Есть и другие, более глубокие преимущества REST, которые вращаются вокруг возможности эволюции через свободную связь и гипертекст, но механизмы кэширования являются основной причиной, по которой вы должны заботиться о RESTful HTTP.