mid1/networking: Add a link about REST architecture

[antonkalinin-ml]

Загуглил "REST myths" и нашел эту статью. Я знал, что-то такое должно существовать :).

Краткое содержание.

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

Впоследствии Филдинг еще раз высказался на тему REST, чтобы прояснить ситуацию, но только всех расстроил. По его мнению, RESTful-архитектура не должна использовать заранее заданные эндпойнты, а обнаруживать их, читая ответы сервера и гуляя по ссылкам (HATEOAS?). Автор говорит, что таких систем не существует.

Автор предлагает следующую трактовку REST: это архитектура, позволяющая промежуточным агентам (прокси-серверам, кеширующим серверам, вообще любым промежуточным серверам, клиентским и серверным библиотекам) понимать что-нибудь о запросе или ответе и делать с ним что-либо полезное, не нуждаясь в понимании тела запроса. Это стандартные заголовки, методы, URI, статусы. Отсюда легко понять, что для REST важно, а что нет:

• для метода важно не название, а то, является ли он идемпотентным, рид-онли, кешируемым, потому что эти свойства полезны для промежуточных агентов. Прокси-сервер может автоматически перезапускать идемпотентные запросы, если не получил ответ, облегчая клиенту задачу обработки этой ситуации. Создавать сущности необязательно через POST, лучше через PUT. PUT лучше PATCH, так как он идемпотентный.
• кодирование информации в URI хорошо тем, что промежуточные серверы могут подменять части URI на основе заголовков (например, проверяя авторизацию и удаляя заголовок Authorization)
• кеширование при помощи кеширующих заголовков позволяет клиентской библиотеке автоматически кешировать контент, так что программисту не придется вообще об этом думать.

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

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