Comments 26
REpresentational State Transfer ни словечка про это. Таким образом первое правило не существует.
Второе правило про HTTP, но не про REST
Третье правило про кэширование, но не про REST
Четвертое правило - протокол (HTTP) и архитекnрутный стиль (REST), как следует из википедии, не одно и то же. Не стоит путать тёплое с мягким. Правила протокола нарушать нельзя, архитектурные правила, можно, если очень захотеть.
И далее всё про HTTP, а не про REST.
И это ещё никто не упомянул про RESTful
По-моему, у автора вполне соответствует тому что написано в оригинале - немного своими словами, но достаточно близко.
HTTP - это реализация стиля REST. Это, конечно, не одно и то же, но и не теплое с мягким. Если мы говорим про HTTP - мы говорим про REST, просто в более узком его понимании. И кэширование входит в понятие REST (и в HTTP возможность кэширования реализована также).
SOAP и GraphQL тоже реализации REST? Или все-таки HTTP это транспортный протокол (читай уровень) а REAT API, JSON API, SOAP и GrathQL протокол приложения.
Пожалуйста, почитайте про модель OSI. Я конечно сам раньше плавал в понимании, что есть, что, но фраза - "HTTP — это реализация стиля REST" - это что-то за гранью.
Пролистав первую половину статьи, возрадовался - рассказано просто, правильно и главное - без всяких джисонов и хттп! Ан нет, появились потом..
По существу: классная статья, рассказано именно базовые вещи без воды и отвлечение. Автор - крутая! Дай пожму лапу
А без HTTP и JSON не получится, REST на них жёстко завязан, прибит, так сказать, гвоздями.
Строго говоря нет. В оригинальной работе Роя Филдинга, который в ней первым сформулировал принципы REST (и на которую я выше приводил ссылку) HTTP приводится только как пример протокола по которому могут взаимодействовать части распределенной REST-системы, но какого-то прямого требования, что этим протоколом может быть только HTTP вовсе нет.
Спасибо большое за поддержку:)
Я бы хотела объяснить без json и http, но начинающие специалисты разбирая эту тему все равно бы о них споткнулись)
Статья больше похожа на "http для дошколят"
А мы точно получим ответ и статус от сервера, если он выключен? Статья действительно больше описывает протокол http, чем REST.
Если сервер отключен или недоступен, то обычно будет отображаться сообщение ошибки "504 Gateway Timeout" или "503 Service Unavailable". Эти ошибки указывают на то, что сервер не отвечает на запросы вовремя из-за проблем соединения или отказа сервера обрабатывать запросы. Также может отображаться сообщение о том, что "страница не может быть загружена" или что "сайт недоступен". В любом случае, если сервер отключен, пользователи не смогут получить доступ к сайту до тех пор, пока сервер снова не станет доступен.
Думали мы с вами, думали и передумали, чтобы Шани участвовал в Котовыставке. Решили удалить его анкету. Давайте посмотрим, как будет выглядеть такой запрос.
Юля, может проще табличкой?)
Котики это топ в любом случае, одобряю:D
Вопрос: а как в соответствии с этими правилами должен выглядеть запрос, возвращающий котиков породы мейн-кун и британских вислоухих, отсортированных по возрасту и числу призов?
Например:
GET /api/cats/?$filter=Breed in('мейн-кун', 'британский вислоух')&$orderby=(Age, PrizeCount)
Скорее так
GET /api/cats?breed[]=maine_coon&breed[]=british_fold&$order_by[0]=age&order_by[1]=prize_countНапример вот так GET api/cats?breed=maine-coon,british-shorthair&sort=age,prizes
Такой запрос, конечно, можно сформировать при помощи скрипта на фронтэнде и даже распарсить его на бэкэнде, применив, возможно, не самый стандартный подход, но подумайте, как будет выглядеть запрос с применением обычной html-формы и таких тегов, как <input type="ckeckbox"> или <select multiple>. У этих элементов будут атрибуты name и value, что будет значить "ключ" и "значение", отражаемые в запросе, и применение одинаковых имён позволит последним выбранным значениям перезаписать предыдущие.
Можно глупый вопрос? Почему для изменения используется PUT, а не PATCH, и зачем в PUT мы отправляем все данные, а не только те, что надо поменять?
PATCH как раз для того и придуман, чтобы отправлять только те данные "что надо поменять". PUT отправляет все (хотя, строго говоря, не обязан) - это просто такая традиция и негласное соглашение.
PUT перезапишет данные объекта (если он есть) или создаст его (если не было), поэтому данные нужны все.
А использовать ли PUT или PATCH - зависит от бизнес-ситуации. Если "нужен вот такой котик, был он или нет" - это PUT; "у существующего котика изменить то-то и это" - PATCH
REST API на котиках