а в рельсах (Ruby on Rails) наоборот

мм тред о КРУДАХ пошёл

но это всё сорта говна конечно

НЕУЖЕЛИ ТЕМА МОНОИДОВ И ДУ НОТАЦИЙ

ИСЧЕРПАЛА СЕБЯ

не прав, конечно

много где именно так, но я не очень знаком про философию реста.

много где именно так, но я не очень знаком про философию реста.

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf так просто диссертацию читни %)

я лючше теоркат, спасибо

риспект

я всегда считал что POST это эквивалент CREATE в сиквеле, а PUT - эквивалент UPDATE. Возможно не прав.

В случае реста вы правы, а за его пределами есть два метода, которые совершенно точно будут работать - post, не кэшируется, get, кэшируется

Yes, you can send a request body with GET but it should not have any meaning. If you give it meaning by parsing it on the server and changing your response based on its contents, then you are ignoring this recommendation in the HTTP/1.1 spec, section 4.3: [...] if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request. And the description of the GET method in the HTTP/1.1 spec, section 9.3: The GET method means retrieve whatever information ([...]) is identified by the Request-URI. which states that the request-body is not part of the identification of the resource in a GET request, only the request URI.

Ну а то, что post дефакто юзают для получения ресурса, это спецификации не противоречит?

нет

В принципе тогда весь рест можно писать через POST, нуачо?

и назвать его POSTREST

riprest

о!

> путать REST и HTTP

REST не нужен. HttpRpc через post это правильно

кул стори бро

REST не нужен. HttpRpc через post это правильно

Вот он шарит ^

Смотри апишку дропбокс. Интегрировать одно удовольствие

В принципе тогда весь рест можно писать через POST, нуачо?

и назвать его JSONRPC

и назвать его JSONRPC

вот кстати json-rpc норм тема

я так делал

и назвать его POSTREST

postgres

https://postgrest.org/ шах и мат

На хаскеле написан

https://postgrest.org/ шах и мат

все мемы написаны до нас

С json-rpc, как и со всеми RPC основная проблема такая, что спустя какое-то время мы получаем множество весьма специализированных методов, которые заточены на конкретные методы классов уже внутри сервисов. А также появляются куча методов, которые хочется удалить, но неизвестно - вдруг их ещё кто-то использует? А также ещё маленькая кучка, которую бы надо удалить, но жалко.

Смотри апишку дропбокс. Интегрировать одно удовольствие

Вооот, чисто POST-ы, респект ребятам из Дропбокса, не побоялись в публичном апи грести против "философии реста".

Вооот, чисто POST-ы, респект ребятам из Дропбокса, не побоялись в публичном апи грести против "философии реста".

эм, кроме реста есть и другие философии

и даже поверх http

С json-rpc, как и со всеми RPC основная проблема такая, что спустя какое-то время мы получаем множество весьма специализированных методов, которые заточены на конкретные методы классов уже внутри сервисов. А также появляются куча методов, которые хочется удалить, но неизвестно - вдруг их ещё кто-то использует? А также ещё маленькая кучка, которую бы надо удалить, но жалко.

и чем рест тут поможет?

в ресте у тебя все теже методы, просто они выглядят как ресурсы

и чем рест тут поможет?

Рест имеет какую-никакую но тенденцию к обобщению. Лично я редко видел METHOD /xxx/<имя_метода_в_классе> А в RPC неоднократно. Понятно, и в канонiчном рест, и в rpc можно сделать и хорошо, и отвратительно - но поведение по умолчанию в ресте общее, а в RPC специализированное.

на хабре была неплохая статья, почему рест говно

ксли коротко: не ложится на рест философию реальное приложение

https://habr.com/company/mailru/blog/345184/

вот эта походу

спасибо, читану

Рест это ненужное усложнение rpc. Параметры идут аж в трех местах вместо одного

спасибо, читану

цитатку наброшу, одну из Хотите с помощью PUT обновлять свои ресурсы? Ладно, но Пресвятые Спецификации утверждают, что ввод данных должен представлять собой «полный ресурс» (complete resource), т. е. нужно следовать той же схеме, что и у вывода данных с помощью GET. И что вы будете делать с многочисленными параметрами только для чтения, возвращаемыми командой GET (время создания, время последнего обновления, сгенерированный сервером токен…)? Вы пренебрегаете ими и нарушаете принципы PUT? Вы в любом случае их вставляете и ожидаете «конфликта HTTP 409», если они не совпадают с серверными значениями (потом заставляя вас отправлять GET…)? Вы даёте им случайные значения и ожидаете, что сервер будет их игнорировать (удовольствие от тихих ошибок)? Выберите, что вам ближе, REST не даёт ясного понимания, что такое атрибут только для чтения, в ближайшем будущем эта ситуация не изменится. При этом опасность GET в том, что он должен возвращать пароль (или номер банковской карты), который затем отправляется в предыдущий POST/PUT — удачи вам и с этими параметрами только для записи. Хотите для обновления своего ресурса использовать PATCH? Прекрасно, но, как и 99 % людей, использующих глагольные команды, будете просто отправлять в полезных данных своего запроса подмножество полей ресурса в надежде, что сервер правильно поймёт, что вы хотели сделать (со всеми возможными побочными эффектами). Многие параметры ресурсов глубоко взаимосвязаны или обоюдно эксклюзивны (например, в данных о пользовательском счёте указывается номер банковской карты ИЛИ токен PayPal), но RESTful-архитектура скрывает и эту важную информацию. Но вы в любом случае опять нарушите спецификации: PATCH не должен отправлять кучу полей для переопределения. Он должен отправлять «набор инструкций», которые будут применяться к ресурсам. Так что берите блокнот и кружку с кофе, придётся определиться с выражением этих инструкций и их семантикой. Не-изобретённый-здесь синдром — это стандарт де-факто в мире REST. Хотите удалять ресурсы с помощью DELETE? Ладно, но надеюсь, вам не понадобится предоставлять важную контекстную информацию типа PDF-скана пользовательского запроса о расторжении. DELETE не должен содержать полезную информацию. Этим ограничением REST-архитекторы часто пренебрегают, потому что большинство веб-серверов не заставляют соблюдать это правило в запросах к себе. Но насколько совместимым будет DELETE-запрос с прикреплённой двухмегабайтной base64-строкой запроса?

Лолочник: I don't have time to write a whole essay, so let me just establish my credentials: I wrote the generic associated types RFC (how Rust will implement higher kinded polymorphism). I wrote the const generics RFC (the closest Rust will get to dependent types). I wrote the async/await RFC, as well as the linked blog post. That is to say that I am intimately familiar with how Rust's type system can be extended to support more "powerful" abstractions. Monads as implemented in pure functional programming languages like Haskell cannot usefully abstract over asynchronous and synchronous IO in Rust for a variety of reasons having to do with the way the type system exposes low level details by virtue of Rust being a systems programming language. I do not believe that do notation could be a useful mechanism for achieving either the ergonomics or the performance that async/await syntax will have in Rust. I'm responding to you because you're the top comment, but I could write a similar response to a lot of comments here. Monads, stackful coroutines, green threads, CSP, etc - we've heard of them! :) We have well-motivated reasons to choose async/await: its the only solution that meets our requirements.

Here are three problems: Higher kinded polymorphism results in trivially undecidable type inferences without something like currying; the restrictions needed to support it would be arbitrary and weird given that Rust does not have currying (essentially some rules to reconstruct the restrictions of currying in type operator context). Instances of both Future and Iterator do not implement the Monad type class as defined in Haskell, because the "fmap" operator does not return the "self" type parameterized by a new type, it returns its own new type. This is because the state machine they represent is leaked through their function signature. Do notation doesn't work with the imperative control flow that Rust has, which other people have already discussed.

To get started you need Cargo's bin directory ($HOME/.cargo/bin) in your PATH environment variable. Next time you log in this will be done automatically.

Не совсем понял

Что туда прописать ?

$ export PATH="$HOME/.cargo/bin/:$PATH"

Это с env надо скопировать ?

с какого env? что скопировать?) я ж вроде команду готовую написал )

Спасибо

В файле env тоже самое

ну тогда можно просто открыть новую консольку и там уже .cargo/bin должно быть в PATH

на хабре была неплохая статья, почему рест говно

У реста главная проблема в том что в вебе rest-ом называют все

кого не спроси что такое рест, каждый скажет чтото свое

рест он как бог - ощущают его все по разному

)

я сегодня в шутку предложил для фронта делать API на soap

я сегодня в шутку предложил для фронта делать API на soap

тебя там не убили?

))) хотели

за soap заточку в печень - никто не вечен

))))

рест он как бог - ощущают его все по разному

Нее, ты ошибаешься

/me теперь всегда делает как дропбокс

ловите этого иркомана

У реста главная проблема в том что в вебе rest-ом называют все

там так оно и написано

rest - new soap жеж

и действитекльно

я долго думал, что я тупой его не понимаю, а все умные

оказывается никто нихера не понимает

Как вы сопоставите точные функции из приведённого примера с CRUD-операциями? Является ли отправка напоминающего письма обновлением атрибута must_send_activation_reminder_email? Или созданием activation_reminder_email resource? Разумно ли использовать DELETE для cancelSubscription(), если подписка остаётся живой в течение grace-периода и в любой момент может быть активирована? Как вы распределяете по конечным точкам дерево данных getAccountDetails(), чтобы соответствовать модели данных REST?

Как вы сопоставите точные функции из приведённого примера с CRUD-операциями? Является ли отправка напоминающего письма обновлением атрибута must_send_activation_reminder_email? Или созданием activation_reminder_email resource? Разумно ли использовать DELETE для cancelSubscription(), если подписка остаётся живой в течение grace-периода и в любой момент может быть активирована? Как вы распределяете по конечным точкам дерево данных getAccountDetails(), чтобы соответствовать модели данных REST?

не спойлери, я только начал читать

я сегодня в шутку предложил для фронта делать API на soap

Хочешь потроллить, предлагай CORBA, если очень толсто то DCOM

Да, для фронтенда.

)))

ну Corba поверх HTTP должна быть тогда

Поверх вебсокетов

Чтоб наглухо