Программирование, т. 7

 

Подскажите  какая категория Категории  в программирования для создания бота?

Категория "Программирование" , а какая подкатегория зависит от бота и что он должен уметь

 

спс

Я юзаю пут для обновления данных и делит для удаления, это хорошая и правильная практика

Я хз с чего ты взял, что это не юзается

 

Статья по REST https://habr.com/post/351890/

Вот с нее по методам http://joxi.ru/zANpZyjuBDnzam

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

ни один никогда ничего кроме пост-гет не юзал

сейм с тем что я видел в хттп-сниффере. ничего у меня в системе не делало не-пост/гет запросов

Мне нужно, что GET-запросы кешировались, кроме тех, что идут через AJAX. Есть легкий способ это сделать?

Подставлять к строке запросы рандомные цифры/время нельзя.

 

кэширование же через хидеры контролируется, если я правильно помню

настроить апи чтобы любой ajax содержал хидер "не кешировать"

 

о я чето не видел толком нигде упоминаний PUT и DELETE кроме как "они существуют", всё гет или пост.

 

Погугли CRUD 

 

не круд, а Richardson Maturity Model https://martinfowler.com/articles/richardsonMaturityModel.html

 

Я юзаю пут для обновления данных и делит для удаления, это хорошая и правильная практика

Я хз с чего ты взял, что это не юзается

 

Статья по REST https://habr.com/post/351890/

Вот с нее по методам http://joxi.ru/zANpZyjuBDnzam

интересно

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

ни один никогда ничего кроме пост-гет не юзал

 

сейм с тем что я видел в хттп-сниффере. ничего у меня в системе не делало не-пост/гет запросов

 

ты не думал что форумы - вещь обычно примитивная

и обычно там не то чтобы высокопрофессиональные спецы занимающиеся внесением новых фич 8/5 

там достаточно костылей и велосипедов напихать и усё будет летать

я именно про сложность бизнес-логики

еще в джаве есть spring data которая из коробки предоставляет crud по entity из бд

тоесть ты просто сказал - вот для этого класса который мапится ORMом в базу сделать crud rest api

и всё. у тебя crud из бд мапится напрямую в post, get, put, delete методы контроллера

жаст дуит, скажи, тебе зп дают за хитровыебанные посты на пд?

 

Я юзаю пут для обновления данных и делит для удаления, это хорошая и правильная практика

Я хз с чего ты взял, что это не юзается

 

Статья по REST https://habr.com/post/351890/

Вот с нее по методам http://joxi.ru/zANpZyjuBDnzam

интересно

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

ни один никогда ничего кроме пост-гет не юзал

 

сейм с тем что я видел в хттп-сниффере. ничего у меня в системе не делало не-пост/гет запросов

Просто почти все эти форум движки, наполнены кучей говна и отсутствие пут и делит методов, это не главная их проблема

я понимаю что можно мапить операции на соотв. типы реквестов

просто если смотреть на описание протокола

то мне сложно представить что на современных сайтах (как минимум со стороны юзера, браузер которого шлёт эти реквесты) могут выполняться условия прописаные в стандарте

типа

> The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

или

> The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

всё всегда упирается в адрес

 

Не просто ж так придумали помимо POST еще всякие GET/PUT/DELETE

а теперь реквестами ты общаешься почти исключительно с бекенд кодом, а хттп по сути стал чисто таким себе транспортом сложных запросов к беку как тсп тупо передаёт пакеты и всё

и дальше бек сам делает всё что надо и ему похуй какой тип реквеста в хттп заголовках

 

помоему бред

тк есть всякие nginx, балансировки, промежуточное "железное" кэширование, перенаправление

основанное именно на http

хоть я и понял аналогию, но она сильно не корректна если вдуматься

тсп же про то что у тебя есть 2 конкретных узла и нужно "гарантированно" передать порцию данных

http же про уже то что у твоего сервиса бывают статичные страницы и их можно кешировать, есть мобильные клиенты, есть все остальные, есть там определенная мета инфа, есть mime type, который например позволяет тебе понять некая строка, типа, "aushdfauhsdfhasdkfjhjasd" строка это, скажем, base64 закодированная штука или plain text

в общем http это не просто url, а дальше бекенд во всем разберется. дает то что на основании спеки + современных бест практисес ты можешь из коробки получить нужное тебе функционирование зависящее от некоей специфичной приложению/системе бизнеслогики, причем чуть ли не на железном уровне (я имею ввиду когда ты вставляешь промежуточный кэш в виде отдельного сервиса в котором стоит примитивный системный софт на C который чисто по заголовку решает кэшировать или нет часть запросов)

функции хедеров я знаю

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

но это точно так же как сервисная инфа в тсп, только для веба

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

щас хуй ты сделаешь сайт где это возможно

мало того вот мы говорим гет типа только достаёт инфу и ничего не меняет

но это тоже не совсем так. он отчасти всё-равно меняет контент т.к сайт постоянно логгирует просмотры и апдейтит их цифру или условный фейсбук на основе этого тебе меняет рекомендации и т.д.

но это тоже не совсем так. он отчасти всё-равно меняет контент т.к сайт постоянно логгирует просмотры и апдейтит их цифру или условный фейсбук на основе этого тебе меняет рекомендации и т.д.

Ну это побочное

 

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

щас хуй ты сделаешь сайт где это возможно

 

 

Почему? Что мешает так сделать? Мне кажется ты видишь проблему там, где ее нет

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

щас хуй ты сделаешь сайт где это возможно

я что-то вообще не понял про что ты здесь говоришь

ты про какие-то конкретные софтверные решения которые так работали?

ты уверен что у тебя не искривленное восприятие тем что ты только определенный класс серверов (конкретных решений) рассматривал в силу того что решал один круг задач (браузерные движки, лендинги, cms-ки и тд)

на джаве такого никогда не было

там вообще были SOAP вебсервисы

я понимаю что можно мапить операции на соотв. типы реквестов

просто если смотреть на описание протокола

то мне сложно представить что на современных сайтах (как минимум со стороны юзера, браузер которого шлёт эти реквесты) могут выполняться условия прописаные в стандарте

 

типа

 

> The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

 

или

 

> The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

 

всё всегда упирается в адрес

и действительно чуваки с фронта кидали апдейт именно через put

а бекендеры у себя писали методы контроллера не по названию а по методам (ну не писали, а за них это делал фреймворк)

ты уверен что у тебя не искривленное восприятие тем что ты только определенный класс серверов (конкретных решений) рассматривал в силу того что решал один круг задач (браузерные движки, лендинги, cms-ки и тд)

моё видение хттп именно как протокола передачи гипертекста и пока всё с чем я сталкивался именно так и выглядело

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

Что мешает так сделать?

ну типа у тебя по /forum/topic/212126 находится топан и ты отправляешь какой-нибудь DELETE /forum/topic/212126 { token=xx } с идеей что после выполнения запроса по этому адресу топан будет недоступен вместо POST forum/topic/delete { topic=212126&token=xx } и чем одно принципиально лучше другого?

я чето подобное этому имел ввиду когда говорил о том что "бек этим занимается"

типа что логичнее что /forum/topic/delete на уровне бека отвечает за приём запроса на удаление вместо смены типа запроса и реюза URI

Конечно смена типа запроса более семантична, логична, чиста, проста и удобна

моё видение хттп именно как протокола передачи гипертекста и пока всё с чем я сталкивался именно так и выглядело

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

кстати а лайк на фотку это тогда пут или пост?

Ну если ты создаешь какой-то объект лайк в таблице лайков то пост

А если обновляешь счетчик у объекта юзер то пут

Ну если ты создаешь какой-то объект лайк в таблице лайков то пост

А если обновляешь счетчик у объекта юзер то пут

если точнее то для меня "тип реквеста" это довольно странная абстракция т.к. делить реквесты извне на создать получить изменить удалить не смотря на то что довольно логично... но как по мне как-то слишком грубо и узко чтоли

это выглядит как дизайн API для ручного браузинга по телнету

ты такой типа

telnet prodota.ru

OPTIONS

GET index.html

*смотришь свежие новости*

GET news/icefrog_eto_gaben

*поржал и решил оставить камент*

POST login { user=xx&password=hunter2 }

PUT news/icefrog_eto_gaben/comments/ { text="ya tak i znal" }

PATCH user/xx/profile { biography="vi vse pidori" }

PATCH user/xx/profile { avatar="C:\kotiki\kotik291.jpg" }

и пр.

пу сути чтоб браузинг был как консольные программы с CLI аргументами

 

Ну если ты создаешь какой-то объект лайк в таблице лайков то пост

А если обновляешь счетчик у объекта юзер то пут

не наоборот?

 

если точнее то для меня "тип реквеста" это довольно странная абстракция т.к. делить реквесты извне на создать получить изменить удалить не смотря на то что довольно логично... но как по мне как-то слишком грубо и узко чтоли

я наконец вспомнил что мне изначально казалось странным в этой схеме

это выглядит как дизайн API для ручного браузинга по телнету

 

ты такой типа

 

telnet prodota.ru

OPTIONS

GET index.html

*смотришь свежие новости*

GET news/icefrog_eto_gaben

*поржал и решил оставить камент*

POST login { user=xx&password=hunter2 }

PUT news/icefrog_eto_gaben/comments/ { text="ya tak i znal" }

PATCH user/xx/profile { biography="vi vse pidori" }

PATCH user/xx/profile { avatar="C:\kotiki\kotik291.jpg" }

 

и пр.

 

пу сути чтоб браузинг был как консольные программы с CLI аргументами

 

именно

только ты изобрел велосипед

это https://ru.wikipedia.org/wiki/HATEOAS

в смысле изобрёл

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

поэтому и говорил что веб2.0 делает эти вещи ненужными и вся ответственность типажа запросов передаётся на бек и то как фронт генерирует их. и это разделение запросов на самом базовом уровне ака "тип запроса" кажется довольно искуственным

у меня в вебе не так много опыта, но мне просто в целом сложно придумать пример того где ты можешь проводить манипуляции на уровне URI через хттп
ну типа у тебя по /forum/topic/212126 находится топан и ты отправляешь какой-нибудь DELETE /forum/topic/212126 { token=xx } с идеей что после выполнения запроса по этому адресу топан будет недоступен вместо POST forum/topic/delete { topic=212126&token=xx } и чем одно принципиально лучше другого?

я чето подобное этому имел ввиду когда говорил о том что "бек этим занимается"
типа что логичнее что /forum/topic/delete на уровне бека отвечает за приём запроса на удаление вместо смены типа запроса и реюза URI

не наоборот?