Какой способ построения RESTapi предпочитаете?

Второй так как следует идеям REST, а первый - бред от оопешников.

Первый не соответствует ReST.

не соответствует ReST

Holly shit. Т.н. REST - диссертационный высер, ставивший целью описать веб:

1. Клиент серверная архитектура. Браузер - клиент, сервер - внезапно сервер.
2. Отсутствие состояния у страниц. Можно зайти на страницу /govno.html, не заходя предварительно на /kanalizacia.html.
3. Кеширование. В ответах сервера сообщается, можно ли кешировать файл и на какое время.
4. Слои. Перед сайтом может стоять проксирующий сервер, балансировщик нагрузки и прочая неведомая х-я, о которой пользователь и не подозревает.
5. И т.д.

HTTP - бляха муха REST, потому что REST - это описание HTTP. Вне зависимости от URL или прочей мути. Другое дело что JS обезъяны увидели в REST откровение, новый виток эволюции. И теперь пишут на форумах: «это вообще не REST».

Два чая

Чай себе оставь, он тебе пригодится тушить, когда узнаешь что REST еще описывает модель uri, как идентификатора ресурса а не хрен знает чего как в первом случае.

Ты уверен что правильно меня понял? Я отвечал на сообщение первого анонимуса

А черт, попутал.

В твоем выпуке не хватает ссылок на источники. Раз ты утверждаешь, что

Т.н. REST - диссертационный высер, ставивший целью описать веб:

,то жду библиографию в соответствии с ГОСТом.

Ну ты и обезьяна, осиль википедию:

REST was defined by Roy Thomas Fielding in his 2000 PhD dissertation «Architectural Styles and the Design of Network-based Software Architectures».[4] Fielding developed the REST architectural style in parallel with HTTP 1.1 of 1996-1999, based on the existing design of HTTP 1.0[5] of 1996.

А там найди ссылку на саму диссертацию.

что REST еще описывает

Да, а людей боженька создал из ребра и потрохов. Ты прочёл документ или веры достаточно нынче? Страницу 109 открой, автор предлагает называть URI не «идентификатором документа», а «идентификатором ресурса» (да как угодно). А затем говорит о недопустимости использовать URI для хранения сессии (т.е. тот самый stateless), ибо это плохо кешируется. И описывает HTTP, где ожидается, что GET не выполняет никаких действий. И запрос к любому «ресурсу» может быть выполненым любое количество раз.

subwoofer Покажи, где написано, что URI, приведенные OP не соответствуют стилю REST.

И как раз во введении тут же написано, что

This dissertation defines a framework for understanding software architecture via architectural styles and demonstrates how styles can be used to guide the architectural design of network-based application software. A survey of architectural styles for network-based applications is used to classify styles according to the architectural properties they induce on an architecture for distributed hypermedia. I then introduce the Representational State Transfer (REST) architectural style and describe how REST has been used to guide the design and development of the architecture for the modern Web.

Ты же утверждаешь, что

высер, ставивший целью описать веб

Не стыкуется.

Возвращаясь к теме треда - первый вариант не является ReSTful, потому что URI там не являются идентификаторами ресурсов, а именуют какую-то RPC-like парашу. Пункт 5.2.1.1 в приведенном тобой источнике.

GET не выполняет никаких действий

А, вот как в вашей секте называют не модифицирующие запросы. Может ты в гугле работаешь, переводчиком?

Не стыкуется.

В чём не стыкуется. Он описывает «modern web» (на тот момент) и выделяет, как видит, хорошие и плохие практики. Предлагает REST, представляющий собой как раз набор, как он считает, хороших практик.

первый вариант не является ReSTful
потому что URI там не являются идентификаторами ресурсов

Упоротый что-ли? Очень даже являются. Оба варианта суть одно и тоже. В древних браузерах была поддержка только GET и POST, а в не настолько древних поддержка методов отличных от GET и POST была кривая (https://annevankesteren.nl/2007/10/http-method-support). Потому активно использовался метод 1. Кроме того, в HTML 4 методы отличные от GET и POST были вовсе невалидны.

Так что не надо разговоров про то, что что-то там с чем-то несовместимо. Всё исключительно вопрос личных предпочтений. Если вам будет хорошо, то и Roy Thomas Fielding'у будет хорошо.

По сути сказать нечего, насколько я понимаю.

В чём не стыкуется. Он описывает «modern web» (на тот момент) и выделяет, как видит, хорошие и плохие практики. Предлагает REST, представляющий собой как раз набор, как он считает, хороших практик.

Он описывает стиль построения архитектуры веб-приложений с учетом возможностей современного на тот момент веба.

Упоротый что-ли? Очень даже являются. Оба варианта суть одно и тоже. В древних браузерах была поддержка только GET и POST, а в не настолько древних поддержка методов отличных от GET и POST была кривая (https://annevankesteren.nl/2007/10/http-method-support). Потому активно использовался метод 1. Кроме того, в HTML 4 методы отличные от GET и POST были вовсе невалидны.

Ты либо не очень смышленый, либо очень жирный. Я тебе про то, что /govno/mocha/1/add и /govno/mocha/432/delete не являются идентификаторами самостоятельных ресурсов, и поэтому не ReSTful, а ты мне про поддержку HTTP-методов браузерами. Какая вообще разница, что поддерживается браузерами, если речь об API? Тем более, что методы, отличные от GET и POST в HTML формах до сих пор не поддерживаются. Просто потому что некому накидать RFC.

Так что не надо разговоров про то, что что-то там с чем-то несовместимо.

Не знаю, что ты там с чем совмещаешь. Вероятно, ужа с ежом.

Всё исключительно вопрос личных предпочтений.

У вас всегда так, а потом некому поддержать разваливающуюся постмодернистскую цифровую инсталляцию, которую г-н Анонимус так сделал, потому что он так видит.

Он описывает стиль построения архитектуры веб-приложений с учетом возможностей современного на тот момент веба.

Из тебя хороший рерайтер получится.

Я тебе про то, что /govno/mocha/1/add и /govno/mocha/432/delete не являются идентификаторами самостоятельных ресурсов, и поэтому не ReSTful

Тебе это Рабинович на ушко нашептал?

Ты или туп или притворяешься. Склоняюсь к первому. Я выше отметил, что Филдинг назвал REST'ом. Выбору URI он как-то внимания не уделил особо. Может он потом лично тебе позвонил и дополнил свой стиль архитектуры REST или ты умеешь читать между строк.

О чём Филдинг писал в контексте URI, так это о том, что должен быть uniform interface (речь про иерархическую природу идентификатора) и адрес ресурса не должен меняться. Всё. Свои влажные фантазии оставляй при себе.

второй, только так

/api/users/     # method: get (get users list)
/api/users/<id> # method: get (get user info)
/api/users/new  # method: post, add new user
/api/users/<id> # method: post (edit user)
/api/users/<id> # method: delete (delete user)

Ты или туп или притворяешься.

Всё, понял. Может быть даже не сильно туп. Просто адепт секты Gopher'ов. Принятие на веру всего, что насрал в твиттере созда...один из разработчиков Go - аналог смирения в правос-и. Какие там нонче заповеди? Не произноси слова «фреймворк», ибо Господь не оставит без наказания того, кто произносит Это (обходится с помощью Б-г «тулкит»). Трижды на дню читай нама...следующую молитву: REST микросервис микросервис REST.

Второй так как следует идеям REST, а первый - бред от оопешников.

Вообще интересно посмотреть ответ на сей вопрос со стороны бэкэндщиков и фронтэндщиков. Кому какой вариант проще будет реализовать - первый, или второй?

зависит от фрймворка, потому что та в принципе пофиг, ну кое где (spring) я встречал что PUT не все поддерживает и надо костыли навешивать

Ты слегка промахнулся.

Ты или туп или притворяешься. Склоняюсь к первому. Я выше отметил, что Филдинг назвал REST'ом. Выбору URI он как-то внимания не уделил особо. Может он потом лично тебе позвонил и дополнил свой стиль архитектуры REST или ты умеешь читать между строк.

О чём Филдинг писал в контексте URI, так это о том, что должен быть uniform interface (речь про иерархическую природу идентификатора) и адрес ресурса не должен меняться. Всё. Свои влажные фантазии оставляй при себе.

Всё

я скозал!!!!!!

Второй мне кажется более предпочтителен для API, который будут использовать сторонние приложения, а вот первый для views, когда HTMLные формы не умеют put, delete, а всякие костыли, вроде AJAX или скрытых полей не хочется использовать. А на самом деле users.jsf?id=3&action=delete&sessionid=<session id> самый идеальный вариант, а ваши хипстерские RESTы никому не нужны.

Каноничный рест говно. Выноси побольше параметров в query string, получишь бесплатное логирование. К тому же все петушки здесь кудахтающие про DELETE кококо, PUT кококо, окромя этих «глаголов» ничего про REST не знают.

А на самом деле users.jsf?id=3&action=delete&sessionid=<session id> самый идеальный вариант,

И тут юзер нажал F5, мухаха.

Вот! Как раз, заодно, отучит нажимать, куда не надо. ☻

кому что проще реализовать - их личные половые трудности, заявляешь REST API - вынь да положь. и то, что белка пальцы гнет на ровном месте, а анон прав в том, что каноничность RESTa переоценена, ничего не меняет: правильно - второй, первый - лажа и профанация

кому что проще реализовать - их личные половые трудности, заявляешь REST API - вынь да положь.

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

а если там не «в частности web, реализованный на жаваскрипте» (который всегда собой представляет костыль), а зоопарк всего, от 3rd party бэкендов до мобильного говна? под всех подстраиваться и устраивать соцопрос? API - это соглашение, REST API - это типовое соглашение, нехер изобретать непонятно что вместо него

Я предпочитаю гет только на хытымли, а все остальное постом.

И вообще: нонче очень хорошо развился libwebsockets, крайне рекомендую! Вот только выясню, почему они без DNS не хотят работать, и вообще будет классно!

А то CGI-шки — все-таки, как-то кривовато (приходится межпроцессное взаимодействие организовывать, в то время как вебсокеты требуют лишь межпотокового).

REST API - это типовое соглашение

В какой реальности? Я вот могу только назвать гугловский feed-api. И то они потихоньку от этого уходят. 99% так называемых REST API не содержат uri в выдаче, а 80% не смогут работать за кеширующими проксями.

80% не смогут работать за кеширующими проксями.

За кеширующими да. Но и вебдваноль тоже не всегда сможет полноценно за кеширующими проксями работать.

Значит не называй свою апишку REST. Пойнт в этом.

В смысле?

По определению, если api не может работать за кешом, она не REST.

И если в ответах не содержиться uri на прилагающиеся айтемы, то это тоже не REST. И далее по пунктам.

То есть, если ты раз десять шлешь на сервер запрос типа «curl -X DELETE serverna.me/user/userlogin/» а тебе сервер отправляет ответ OK: 200 и какую-нить инфу типа «{error: 0, userid: <id>, status: deleted}» на каждый твой запрос из-за кривонастроенного левого кеширующего прокси - то это уже не рест?

Прочти уже что такое REST. Оригинальная статья не слишком большая.

Рекомендую тебе самому прочесть, а здесь высказать тезисы в знак усвоения материала.

Гг. Много нового узнал после того как прочитал эту тему. Анонимус особенно доставляет. Как всегда в своем стиле.
По теме: конечно же второй вариант, но раз уж вы применяете методы, которые «современный» web ниосилил, то рекомендую присмотреться и к PATCH для частичного обновления ресурса.
Теперь отступление для негодующих в плане «REST откровение, новый виток эволюции», «ваши хипстерские RESTы никому не нужны», «что каноничность RESTa переоценена» и т.д. и т.п.

• Во-первых, о какой области вы тут все говорите? REST не панацея от тупняков, и уж тем более не канон разработки ПО в общем и целом. У него есть определенная ниша, не более.
• Во-вторых, REST представляет из себя архитектурный стиль, а не «свод правил», как тут выразились некоторые. Это не одно и тоже. Кто о чем, а анонимус, как всегда о своем: «REST - это описание HTTP». Ну ок. Может быть именно потому что это докторская диссертация, ты ее и не осилил, а просто начал вырывать знакомые фразочки из контекста. О чем сам контекст, ты, естественно, не понял. Объясню для тебя, это диссертация о исследовании архитектур программного обеспечения, где REST - всего лишь еще один предложенный автором архитектурный стиль. HTTP там - всего навсего один из подтекстов. Да и то, просто потому что другого добротно-описанного протокола в то время не было. Был бы, ты сейчас ко-ко-кокал бы совершенно о другом. Ну то есть о чем угодно - а не архитектурных стилях, о чем, собственно, и нужно было говорить. Будь так добр, осиль документ.
• Про то, кому они нужны, а кому не нужны я думаю будут ко-ко-кокать всегда и всюду. А приводить весомые аргументы для своих слов научатся только единицы.

REST - перво-наперво идеология. А не тупо набор правил. Здесь очень важно понятие ресурса. Ресурс это базис самой системы. Я уже писал здесь, на форуме, что довольно распространенная проблема многих в недопонимании REST'а - это их неверное представление самой модели. Самая простая аналогии - абстрактный автомат из теории алгоритмов. То есть машина/ресурс/«чтоугодно» в один момент времени имеет одно состояние. Все что делаете вы - это либо изменяете это состояние, либо получаете его. Больше ничего. Тут же из REST'а сделали не пойми что.

99% так называемых REST API не содержат uri в выдаче, а 80% не смогут работать за кеширующими проксями.

А вот проблема «бутылки изнутри». Пусть ее разработчики сервиса и решают. Схему запросов к ресурсам проектирует совсем другой человек.

POST создание а PUT модификация? Почему не наоборот?

Воинствующее невежество, как это мило.

По теме: конечно же второй вариант

Почему? Ведь «REST представляет из себя архитектурный стиль, а не «свод правил», как тут выразились некоторые». Поэтому схема меппинга должна быть сбоку, не так ли?

REST - перво-наперво идеология. А не тупо набор правил.

Это правда, REST это прежде всего определенные свойства системы. И HTTP методы не при делах. Так еще раз, дружок, причем тут сраный PATCH?

Схему запросов к ресурсам проектирует совсем другой человек.

Которая, как мы выяснили, почти никак не влияет на REST

Надеюсь, теперь ты понял про что вещал анон.

И HTTP методы не при делах. Так еще раз, дружок, причем тут сраный PATCH?

Как это не при делах? Такой же глагол, по Филдингу, там ему и место. Прочитай мое сообщение целиком.

HTTP там - всего навсего один из подтекстов. Да и то, просто потому что другого добротно-описанного протокола в то время не было.

Филдинг привязал REST к HTTP, но никак не описал HTTP с помощью REST (что является дичайшим бредом), как ко-ко-кокает анонимус. Я всего лишь объяснил почему именно HTTP. Я не думаю что знающие люди здесь, думают якобы HTTP такой классный протокол. Я пока совсем мельком пробежал rfc7541 и rfc7540 для второй версии , поэтому пока за него ничего толком не скажу, надо внимательно изучить, но что 1.0, что 1.1 то еще убожество. У Филдинга просто не было другого выбора, это была практически единственная спецификация в то время, близкая своей структурой запроса. Да и не последнюю роль сыграло его авторство в ней.
А теперь, внимание, вопрос. Что было бы, если бы в то время не было ничего подходящего, а Филдинг все равно взялся бы за докторскую? Ответ прост: ему пришлось бы выдумывать еще одну лишнюю абстракцию, но кто знает, может быть он выдумал бы что-нибудь поинтереснее того же HTTP.
Но в итоге мир получил то, что получил. Сейчас практически никто уже не отделяет REST как свободный архитектурный стиль, не зависящий от HTTP. Его с ним «поженили». Что не айс, но люди не виноваты. Филдинг по сути сам все запорол, жалко было ему придумать еще одну абстракцию, а может он пожалел время, а может быть он реально верил тогда, что HTTP станет чем-то большим. Надо хорошо изучить 7541-вую и 7540-вую, вдруг так оно и есть :) На данный момент, именно потому что HTTP так убог, начали появляться уже огороды типа JSON-pure и иже с ними.

Поэтому схема меппинга должна быть сбоку, не так ли?

Не так ли. Схема должна четко отражать определение ресурса.
Даже то, что у автора users вместо user в топике, уже неверно отражает ресурс. Должно быть единственное число, конечно же. Об остальном умолчу.

Которая, как мы выяснили, почти никак не влияет на REST

Не знаю что ты там выяснил, я ничего этого не говорил. Читай внимательнее.

Надеюсь, теперь ты понял про что вещал анон.

Нет.

Должно быть единственное число, конечно же

Опять правила, лол. В оригинальной бумаге ничего про это нет, просто для примера выбрана схема с хттп-методами.

«Надо было больше заниматься, и меньше есть пудинги.» (с)

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’ s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on.

Выделил ключевую фразу. Если для тебя «пользователи» и «пользователь» это одно и тоже, тогда да, можешь юзать хоть users, хоть user. Лично для меня это совершенно разные ресурсы.

Вот тут все отлично описано про REST API.