REST vs GraphQL/RPC (вынесено)

fixxxer

К.О.
Партнер клуба
Да ютубу бы для начала клиентский API обновить, который до сих пор безальтернативно через задницу (вызов глобальной функции после инициализации либы). :)

Paypal как пример - они бы тоже могли бы ничего не менять, раз внедряют (причем везде, и в самом paypal, и в купленном ими braintree) - значит, видят в этом пользу.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Paypal как пример - они бы тоже могли бы ничего не менять, раз внедряют (причем везде, и в самом paypal, и в купленном ими braintree) - значит, видят в этом пользу.
1. у PayPal сейчас выросла конкуренция, финтех на подъеме
2. логика у PP на порядок сложнее, чем "передал параметры, залил файл", там в основе именно действия и события, а в youtube основное - передача данных
 

fixxxer

К.О.
Партнер клуба
Логика в целом имеет тенденцию усложняться, и на этапе проектирования я предпочитаю более гибкие и универсальные решения.
Если уже сложилось такое API на REST и его хватает, ну нормально значит, я ж абстрактно рассуждаю :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Проблемы с REST чаще не в том, что его не хватает, а в том, что его игнорируют.
Берут table data gateway, мапят его на endpoint-ы, потом берут связи таблиц по FK, и мапят эти связи на дополнительные поля в endpoint-ах.
Вместо нескольких сущностей, каждая из которых работает независимо, получается картина маслом - нарушение сразу нескольких ключевых требований REST.
Помог ли бы им GraphQL - для меня вопрос риторический.
 

Adelf

Administrator
Команда форума
Проблемы с REST чаще не в том, что его не хватает, а в том, что его игнорируют.
С ним еще проблема в том, что чтобы быть настоящим REST API там люди вынуждены нарушать Ubiquitos language. Выдумывать новые псевдо-сущности, просто чтобы соответствовать стандарту. делать POST /published-articles, вместо /article/publish. Только здесь обсуждали уже раз 5 это )
 

Вурдалак

I'd like to model your domain
Выдумывать новые псевдо-сущности, просто чтобы соответствовать стандарту. делать POST /published-articles, вместо /article/publish.
REST вообще не накладывает ограничения на то, как должен называться URI ресурса, насколько я себе представляю.
 

Adelf

Administrator
Команда форума
REST вообще не накладывает ограничения на то, как должен называться URI ресурса, насколько я себе представляю.
Но ведь нам все равно придётся где-то иметь некое существительное, которое будет представлять в REST ресурс для опубликованных статей. Хотя в UL этого нет, там есть только глагол publish.
 

Вурдалак

I'd like to model your domain
Но ведь нам все равно придётся где-то иметь некое существительное, которое будет представлять в REST ресурс для опубликованных статей. Хотя в UL этого нет, там есть только глагол publish.
Ну, REST предполагает, что должен быть некий ресурс, у которого будет в списке отношений <link rel="publish" ...>.
Как страница сайта, где есть форма для публикации новой статьи.
Ведь ты не отправляешь напрямую POST-запрос из браузера, ты заходишь на сайт и через него это делаешь.
REST-клиент — своеобразный browser какого-то REST API.
Только вместо HTML, JS и CSS там будут какие-то твои форматы, MIME-types.

А сами URI вообще не должны публиковаться в документации к REST API, иначе это не REST вообще.
URI высасывает клиент из корневого endpoint'а и далее по ссылкам на ресурсы, как это делает web browser.
 

Adelf

Administrator
Команда форума
Я конечно не в курсе как там дело обстоит, но это потребует некоей перестройки мышления у фронтэндеров... т.е. чтобы сделать publish - надо сказать - сделай publish у этого вот объекта. А объектом будет некий товарищ с кучей мета инфы. чот у меня сомнения. тем более, описывать в документации все равно придется. параметры же надо как-то описать. это тебе не GraphQL :)
 

Вурдалак

I'd like to model your domain
Ты описываешь формат media types. Какой-нибудь application/vnd.adelf-api.article+json (просмотр статьи) для статьи и application/vnd.adelf.article-publish+json для отправки на публикацию, например.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Это уже level 3, на практике все болтается где-то между 1 и 2 =)
 

Вурдалак

I'd like to model your domain
Если говорить об исходном значении REST, то только level 3 и может так называться.
Основная суть как раз в hypermedia.
А остальное — «so-called-REST».
 

fixxxer

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

Adelf

Administrator
Команда форума
Ты описываешь формат media types. Какой-нибудь application/vnd.adelf-api.article+json (просмотр статьи) для статьи и application/vnd.adelf.article-publish+json для отправки на публикацию, например.
Выглядит очень тяжеловесно. А где эти media types описывать? Как версионирование вести? Наверно для проекта, по водопаду, где всё полностью описывается сначала, сойдет...

да у вас, блин, просветление
А у тебя на каждом проекте такой красивый REST? С media types на каждый запрос? :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@Adelf к сожалению, я давно не писал протокол с нуля заново, все время поддержка.
 

Вурдалак

I'd like to model your domain
Выглядит очень тяжеловесно. А где эти media types описывать? Как версионирование вести? Наверно для проекта, по водопаду, где всё полностью описывается сначала, сойдет...
Ты так говоришь, будто я когда-либо в жизни REST API пилил. Я даже видел-то, по-моему, чуть ли не один раз в жизни API, который действительно имеет право называться RESTful.

Версионирование, наверное, можно было бы вести с помощью заголовка Accept, с помощью ссылок на разные версии документа. Как ведется версионирование HTML/CSS/JS? Тут ведь прямая аналогия, по-моему. Media types описываются в доке, вот такой MIME type, вот такие поля.

Кстати, в оригинальной работе про REST API тоже упоминалась возможность расширения API путём использования чего-то типа JS. Т.е. по сути это как обобщение web browser. Теоретически могли бы быть какие-то универсальные клиенты, которые понимают большое количество media types.

Но на мой взгляд, это просто всё слишком сложно. Проще писать какие-то частные клиенты, где клиент и сервер понимают как примерно выглядит приложение.
 
Сверху