Pull to refresh
-7
0

Тестер

Send message
мы говорим о RESTAPI не в Вашем комментарии а о трактовке этого термина в повседневной практике разработчиков фактически CRUD
Нить разговора следующая. RESTAPI это не REST. Поэтому тот кто говорит REST это хорошо следовательно RESTAPI это хорошо допускает подмену понятий
я согласен что передавая токен сессии соблюдается 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. И это две разные совершенно несвязанные вещи.
По этому вопросу есть переводная статья на Хабре habrahabr.ru/post/265845
Ну и язык запросов graphql. Если пытаться сделать RESTAPI выразительнее (через разные параметры типа списка запрашиваемых полей, неободимости разворачивавть связанные объекты, фильтры, пагинацию) — то вся простота и изящества куда-то очень быстро уходит. См. апример www.ibm.com/support/knowledgecenter/SSPLFC_7.2.2/com.ibm.taddm.doc_7.2.2/SDKDevGuide/r_cmdbsdk_restapi_objectclass.html
Что такое Полная реализация 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 в простой текстовой форме
В graphql спецификация сервиса это одновременно и исполняемый код и документация. Если Вам известны другие подобные системы назовите пожалуйста их
graphql не бинарный протокол. И генератор кода ему вообще не нужен. Есть попытки сделать скафо
лдинг по переводу в SQL. Но это не генератор кода.
Да, 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. Некоторые правила требуют ещё и хорошего понимания сетевых протоколов. Я их тоже не до конца все понимаю. Поэтому привёл ссылку на статью из надежного источника. Я их использую в рабочем окружении с указанными изменениями. Правила без защиты на уровне веб-сервера не защищают от атак на высокие уровни т.к. приложение валится от исчерпания ресурсов памяти и процессора задолго до исчерпания ресурсов сети. Поэтому статью опубликовала фирма которая делает бизнес на защите не боясь потерять клиентов
По реализации именно transition «из коробки» работет next-like библиотека для Vue.js ru.nuxtjs.org/guide/routes-transitions
Спасибо, Serg_de_Adelantado за информацию по after.js
По переходу между страницами с «лишним» рендерингом у Next.js у меня вопрос возникал, но я до того чтобы разобраться с ним еще не дошел.

Что касается выбора библиотеки для реального проекта, в after.js первый коммит был 5 ноября 2017 года. И пока всего 8 контрибьюторов. Цифры говорять пока что не в пользу такого выбора. Хотя сам проект может быть лучше, чем Node.js.

image
Любой проект начинается с чего-то нового. Но не все такие проекты собирают мощную поддержку со стороны контрибьюторов и используются в рельных проектах. см. http://www.npmtrends.com.

Что касается Next.js — то как я пытался показать в своем посте — это первая библиотека для React.js, которая позволяет разрабатывать универсальные приложения и при этом:
1) собрала 338 контрибьюторов (на сегодняшний день);
2) реализует весь необходимый функционал;
3) постоянно обновляется для совместимости с новыми версиями React;

То есть нельзя отнести Next.js к велосипедостроению т.к ее функционал не может предоставить ни одна библиотека для React.js которая существует в свободном доступе.
12 ...
95

Information

Rating
Does not participate
Registered
Activity