я согласен что передавая токен сессии соблюдается rest а иначе как бы это работало. Но вот по поводу сессий в redis я могу предполагать что будет примерно равный счёт с gwt пока инстансы сервисов запускаются на одном сервере но когда к redis придётся обращаться через сеть — не уверен что будет более масшабируемо. По hatoas какой вывод можно сделать по перейдя по ссылке. что разработки есть. каков их процент использования в resapi реальных сервисах остаётся вопросом.
Ну так давайте сейчас прямо проверим. Принципы REST дотсупны всем www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Хотя я не уверен что их читали 50% тех кто пишет руководства по RESTFullAPI (тут я как раз квантора всеобщности не употребляю если что).
+ 5.1.2 Client-Server — да http протокол предполагает общение клиент-сервер.
+ 5.1.3 Stateless — да http ничего не знает о состоянии клиента. Веб-приложения «научились» нарушать это правило при помощи сессий. И тут же получили оплеуху в виде невозможности масштабироваться. (Поэтому сейчас все чаще можно встретить сессии в виде GWT когда сессия передается в каждом запросе и может быть таким образом расшернеа между серверами)
+ 5.1.4 Cache. Да в http протоколе определены запросы которые кэшируются и которые не кэшируются и как это реализовать.
± 5.1.5 Uniform Interface.
* identification of resources + да идентифицируются по URI
* manipulation of resources through representations — это как бы не входит в http протокол и может трактоваться как данные и представление это не одно и то же. То есть для простого текста данные==преставление. Для html документа, картинки, скрипта браузер сам знает как отобразить эти данные.
* self-descriptive messages — это тоже не уровень http протокола. Означает что все для обработки сообщение должно содержаться в самом сообщении.
* hypermedia as the engine of application state (HATEOAS) — в RESTAPI почему-то не получило широкого распространения.
+ 5.1.6 Layered System Обращаясь к серверу клиент не знает сколько уровней имеется в архитектуре сервера — ну да.
+ 5.1.7 Code-On-Demand — Все что нужно еще закгружается с сервера по требовнию (да, скрипты же загружаются)
Почему-то ни в одном(!) руководстве не упоминается еще два основополагающих принципа:
5.1.8 Style Derivation Summary — который гласит что эти принципы предназначены для выбора архитектуры приложения (а не способов формирование url).
и те упоминается принцип:
5.1.1 Starting with the Null Style — который гласит что нет других никаких ограничений.
Я к чему это все привел. Мое убеждение что есть REST и есть RESTAPI. И это две разные совершенно несвязанные вещи.
Что такое Полная реализация REST HTTP API? Я уверен что ее не существует в природе. Есть стандарт HTTP и его реализация. Есть стандарт OpеnAPI и его реализация. О REST HTTP API можно сказать что есть стандарт? Все проблемы REST HTTP API как раз и заключается в том что стандарта REST HTTP API так и не получилось. И все попытки продвинуться дальше простых CRUD-запросов к ровно одной таблице (без JOIN-ов) приводят к химерным запросам, при этом у каждого разработчика — к своим запросам. Если к этому прибавить время на споры какой статус будет правильным если номер телефона не прошел валидацию и как передавать в посте связанные иденификаторы ({customerId: 16) or {customer: {id: 16}) то потери превысят все мвслимые лимиты. Не ну все так хорошо начинается обычно на REST HTTP API. ToDoApp и все такое.
graphql имеет библиотеки для всех популярных языков. кроме того это не бинарный протокол и запрос можно отправить методом get post в простой текстовой форме
Да, OpenAPI это язык описания спецификаций. Можно в редакторе создавать схему. Чтобы было понятнее вот пример editor.swagger.io как это происходит. Схема выглядит немного устрашающе но есть тулзы например веб-редактор mermade.github.io/openapi-gui Проект молодой но очень интересный.
Многие статьи о REST ссылаются на работу Roy Thomas Fielding «Architectural Styles and the Design of Network-based Software Architectures» как первоисточник определения REST (смотрите пятую и шестую главы этой работы). Рекомендаций использовать http- глаголы GET-POST-PUT-DELETE как единственный способ определения операций вы там не найдете.
Очень верное замечание. Есть REST — без которого интернет сейчас бы не был интернетом. И есть RESTAPI в примитивной трактовке. RESTAPI (CRUD/G-P-P-D) первоначально поражает своей идеей. Потом начинаются вопросы. Если объект имеет связи (а это общий случай) — как понять, когда включать связанне объекты, а когда не включать. До какого уровня «разворачивать» связанные объекты. Какие поля включать в ответ. Или если сказать проще, у RESTAPI нет необходимого разнообразия
Моя мечта начать использовать graphql, который тоже REST, но не RESTAPI. С моей точки зрения graphql имеет уникальные перимущества которе не может дать на сегодняшний день ни одна другая система.
Программный код и документация связаны и никогда не могут рассогласоваться
Клиент сам решает какие поля вернет запрос и какой уровень вложенности объектов ему нужен
Клиент может в одном запросе запрашивать произвольное количество объектов (веб-разработчики уже свыклись с тем что запросов будет много, а вот для мобильных разраотчиков один запрос — один экран это было бы неплохо)
А так же полностью поддерживаю что ни в коем случае нельзя смешивать уровень бизнес-логики и протокола — это о «краноречивых» статусах. Особенно 404 — это нет зебры в зоопарке, или это нет url «зоопарк»?
Я согласен, что сейчас все вспомогательные библиотеки так или иначе ориентированы на статусы. Но мне кажется логичным использовать максимум три из них: 200 и 304 при нормальном ответе плюс какой-нибудь незарезервированный 400-й статус при ошибке.
У after есть и другие проблемы. Например с интеграцией redux. Я пробовал внедрить ее при помощи пользовательского шаблона _document.js (как это описано в документации after) но как оказалось пользовательский шаблон переписывается нативным при рестарте сервера github.com/jaredpalmer/after.js/issues/52.
С учетом того что after только в начале разработки, то это нормально (мелкие и крупные баги). Вопрос создаст ли автор вокруг этого проекта комьюнити или же это будет еще один проект который будет заброшен если не через два месяца то через два года.
В статье по ссылке есть минимально необходимые пояснения. Плюс документация iptables. Некоторые правила требуют ещё и хорошего понимания сетевых протоколов. Я их тоже не до конца все понимаю. Поэтому привёл ссылку на статью из надежного источника. Я их использую в рабочем окружении с указанными изменениями. Правила без защиты на уровне веб-сервера не защищают от атак на высокие уровни т.к. приложение валится от исчерпания ресурсов памяти и процессора задолго до исчерпания ресурсов сети. Поэтому статью опубликовала фирма которая делает бизнес на защите не боясь потерять клиентов
Спасибо, Serg_de_Adelantado за информацию по after.js
По переходу между страницами с «лишним» рендерингом у Next.js у меня вопрос возникал, но я до того чтобы разобраться с ним еще не дошел.
Что касается выбора библиотеки для реального проекта, в after.js первый коммит был 5 ноября 2017 года. И пока всего 8 контрибьюторов. Цифры говорять пока что не в пользу такого выбора. Хотя сам проект может быть лучше, чем Node.js.
Любой проект начинается с чего-то нового. Но не все такие проекты собирают мощную поддержку со стороны контрибьюторов и используются в рельных проектах. см. http://www.npmtrends.com.
Что касается Next.js — то как я пытался показать в своем посте — это первая библиотека для React.js, которая позволяет разрабатывать универсальные приложения и при этом:
1) собрала 338 контрибьюторов (на сегодняшний день);
2) реализует весь необходимый функционал;
3) постоянно обновляется для совместимости с новыми версиями React;
То есть нельзя отнести Next.js к велосипедостроению т.к ее функционал не может предоставить ни одна библиотека для React.js которая существует в свободном доступе.
+ 5.1.2 Client-Server — да http протокол предполагает общение клиент-сервер.
+ 5.1.3 Stateless — да http ничего не знает о состоянии клиента. Веб-приложения «научились» нарушать это правило при помощи сессий. И тут же получили оплеуху в виде невозможности масштабироваться. (Поэтому сейчас все чаще можно встретить сессии в виде GWT когда сессия передается в каждом запросе и может быть таким образом расшернеа между серверами)
+ 5.1.4 Cache. Да в http протоколе определены запросы которые кэшируются и которые не кэшируются и как это реализовать.
± 5.1.5 Uniform Interface.
* identification of resources + да идентифицируются по URI
* manipulation of resources through representations — это как бы не входит в http протокол и может трактоваться как данные и представление это не одно и то же. То есть для простого текста данные==преставление. Для html документа, картинки, скрипта браузер сам знает как отобразить эти данные.
* self-descriptive messages — это тоже не уровень http протокола. Означает что все для обработки сообщение должно содержаться в самом сообщении.
* hypermedia as the engine of application state (HATEOAS) — в RESTAPI почему-то не получило широкого распространения.
+ 5.1.6 Layered System Обращаясь к серверу клиент не знает сколько уровней имеется в архитектуре сервера — ну да.
+ 5.1.7 Code-On-Demand — Все что нужно еще закгружается с сервера по требовнию (да, скрипты же загружаются)
Почему-то ни в одном(!) руководстве не упоминается еще два основополагающих принципа:
5.1.8 Style Derivation Summary — который гласит что эти принципы предназначены для выбора архитектуры приложения (а не способов формирование url).
и те упоминается принцип:
5.1.1 Starting with the Null Style — который гласит что нет других никаких ограничений.
Я к чему это все привел. Мое убеждение что есть REST и есть RESTAPI. И это две разные совершенно несвязанные вещи.
Ну и язык запросов graphql. Если пытаться сделать RESTAPI выразительнее (через разные параметры типа списка запрашиваемых полей, неободимости разворачивавть связанные объекты, фильтры, пагинацию) — то вся простота и изящества куда-то очень быстро уходит. См. апример www.ibm.com/support/knowledgecenter/SSPLFC_7.2.2/com.ibm.taddm.doc_7.2.2/SDKDevGuide/r_cmdbsdk_restapi_objectclass.html
лдинг по переводу в SQL. Но это не генератор кода.
Очень верное замечание. Есть REST — без которого интернет сейчас бы не был интернетом. И есть RESTAPI в примитивной трактовке. RESTAPI (CRUD/G-P-P-D) первоначально поражает своей идеей. Потом начинаются вопросы. Если объект имеет связи (а это общий случай) — как понять, когда включать связанне объекты, а когда не включать. До какого уровня «разворачивать» связанные объекты. Какие поля включать в ответ. Или если сказать проще, у RESTAPI нет необходимого разнообразия
Моя мечта начать использовать graphql, который тоже REST, но не RESTAPI. С моей точки зрения graphql имеет уникальные перимущества которе не может дать на сегодняшний день ни одна другая система.
А так же полностью поддерживаю что ни в коем случае нельзя смешивать уровень бизнес-логики и протокола — это о «краноречивых» статусах. Особенно 404 — это нет зебры в зоопарке, или это нет url «зоопарк»?
Я согласен, что сейчас все вспомогательные библиотеки так или иначе ориентированы на статусы. Но мне кажется логичным использовать максимум три из них: 200 и 304 при нормальном ответе плюс какой-нибудь незарезервированный 400-й статус при ошибке.
С учетом того что after только в начале разработки, то это нормально (мелкие и крупные баги). Вопрос создаст ли автор вокруг этого проекта комьюнити или же это будет еще один проект который будет заброшен если не через два месяца то через два года.
По переходу между страницами с «лишним» рендерингом у Next.js у меня вопрос возникал, но я до того чтобы разобраться с ним еще не дошел.
Что касается выбора библиотеки для реального проекта, в after.js первый коммит был 5 ноября 2017 года. И пока всего 8 контрибьюторов. Цифры говорять пока что не в пользу такого выбора. Хотя сам проект может быть лучше, чем Node.js.
Что касается Next.js — то как я пытался показать в своем посте — это первая библиотека для React.js, которая позволяет разрабатывать универсальные приложения и при этом:
1) собрала 338 контрибьюторов (на сегодняшний день);
2) реализует весь необходимый функционал;
3) постоянно обновляется для совместимости с новыми версиями React;
То есть нельзя отнести Next.js к велосипедостроению т.к ее функционал не может предоставить ни одна библиотека для React.js которая существует в свободном доступе.