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

[fixxxer]

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

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

 

[grigori]

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

1. у PayPal сейчас выросла конкуренция, финтех на подъеме
2. логика у PP на порядок сложнее, чем "передал параметры, залил файл", там в основе именно действия и события, а в youtube основное - передача данных

 

[fixxxer]

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

 

[MiksIr]

и в котором деньги идут от промышленных клиентов с интеграциями - однозначно стандарт и поддержка на всех платформах важнее всего

С такой формулировкой только SOAP

 

[grigori]

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

 

[Adelf]

Проблемы с REST чаще не в том, что его не хватает, а в том, что его игнорируют.

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

 

[Вурдалак]

Выдумывать новые псевдо-сущности, просто чтобы соответствовать стандарту. делать POST /published-articles, вместо /article/publish.

REST вообще не накладывает ограничения на то, как должен называться URI ресурса, насколько я себе представляю.

 

[Adelf]

REST вообще не накладывает ограничения на то, как должен называться URI ресурса, насколько я себе представляю.

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

 

[Вурдалак]

Но ведь нам все равно придётся где-то иметь некое существительное, которое будет представлять в 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]

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

 

[Вурдалак]

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

 

[Adelf]

@grigori как тебе такие стандарты?

 

[grigori]

да у вас, блин, просветление

 

[fixxxer]

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

 

[Вурдалак]

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

 

[fixxxer]

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

 

[Adelf]

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

Выглядит очень тяжеловесно. А где эти media types описывать? Как версионирование вести? Наверно для проекта, по водопаду, где всё полностью описывается сначала, сойдет...

да у вас, блин, просветление

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

 

[grigori]

@Adelf к сожалению, я давно не писал протокол с нуля заново, все время поддержка.

 

[Вурдалак]

Выглядит очень тяжеловесно. А где эти media types описывать? Как версионирование вести? Наверно для проекта, по водопаду, где всё полностью описывается сначала, сойдет...

Ты так говоришь, будто я когда-либо в жизни REST API пилил. Я даже видел-то, по-моему, чуть ли не один раз в жизни API, который действительно имеет право называться RESTful.

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

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

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