не начинай. Уже объясняли ему, не помогло

что объясняли? что если в приложении только get используется, то все, оно не restful?

ну с другой стороны это иногда полезно, сквозь все говно докопаться до истины

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

что объясняли? что если в приложении только get используется, то все, оно не restful?

дА

дА

а почему? Ну вот не используются там post, put и т.д. Все, не рест?

В этом чате материться можно?

только REST это REST, а сайт это сайт. Даже учитывая, что REST это просто "архитектурный прием" и всё равно работает в контексте HTTP

Да ладно! И сайт не может рест-архитектуру использовать?

Да ладно! И сайт не может рест-архитектуру использовать?

я ж написал выше

окай

теперь жду объяснений про то, почему get /пирожки - это не restful

потому что не full =)

Так, ладно. @vskopuk знаешь, что такое PSR-1 ?

э

теперь жду объяснений про то, почему get /пирожки - это не restful

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

ты мне еще не рассказал про то, почему get /пирожки не restful

ты мне еще не рассказал про то, почему get /пирожки не restful

я пытаюсь, на другом примере. Так знаешь?

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

Uniform interface The uniform interface constraint is fundamental to the design of any REST service.[1] The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints for this uniform interface are Identification of resources Individual resources are identified in requests, for example using URIs in web-based REST systems. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server may send data from its database as HTML, XML or JSON, none of which are the server's internal representation.

есть люди с другим мнением

и это не только я )

и это хорошо, что есть другие мнения =)

я пытаюсь, на другом примере. Так знаешь?

не надо на другом. Ты расскажи применительно к пирожкам. Ты же как-то определил, что это не рес т. Вот и назови критерии

не надо на другом. Ты расскажи применительно к пирожкам. Ты же как-то определил, что это не рес т. Вот и назови критерии

мой-то вариант устраивает? ? =)

теперь жду объяснений про то, почему get /пирожки - это не restful

Если смотреть в контексте того, что у тебя такой вот сервиск, который только /get/пирожки - да, рестфул

не надо на другом. Ты расскажи применительно к пирожкам. Ты же как-то определил, что это не рес т. Вот и назови критерии

я тебе уже называл критерии.

мой-то вариант устраивает? ? =)

нет. Ибо "есть другие мнения"

я тебе уже называл критерии.

вот и перечисли, каким критериям не соответствует get /пирожки

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

нет. Ибо "есть другие мнения"

http://xkcd.ru/i/927_v4.png

На самом деле вопрос мы тут спорим о применении REST'a

а не о том, что такое REST

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

а если они не нужны?

На самом деле вопрос мы тут спорим о применении REST'a

ну, все споры про рест начинаются в применении к практике

нет. Ибо "есть другие мнения"

другие мнения того, что именно надо отдавать, но суть того, что отдается, не меняется же.

ну, все споры про рест начинаются в применении к практике

просто сам спор глупый. ты прав, можно использовать как угодно, можно сайты проектировать рестфул

но на*уя?

когда из-за того, что кто-то превратно понял написанное, get /пирожки оказывается не рест

другие мнения того, что именно надо отдавать, но суть того, что отдается, не меняется же.

ты ж написал, что html-страницу отдавать - это не рест

прямо критерий )

просто сам спор глупый. ты прав, можно использовать как угодно, можно сайты проектировать рестфул

некоторые фрэймворки к этому подталкивают

Лично в своем опыте я видел RESTфульные сервисы, с помощью которых налаживалось взаимодействие между различными системами.

некоторые фрэймворки к этому подталкивают

ты не про CRUD случаем?

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

вот давай, рассмотрим ситуацию - есть некое апи, которое использует только методы гет. Оно данные никак не меняет, только выдает по запросу. Так почему get /пирожки не будет rest?

ты не про CRUD случаем?

Yii, RoR

ты ж написал, что html-страницу отдавать - это не рест

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

вот давай, рассмотрим ситуацию - есть некое апи, которое использует только методы гет. Оно данные никак не меняет, только выдает по запросу. Так почему get /пирожки не будет rest?

Потому что get /пирожки не обязано быть пирожками. Не важно, в каком формате, но в ответ должен прийти список прирожков.

все же тут, имхо, больше на субъективные варианты восприятия сути REST рассчитано

Yii, RoR

Yii это php фреймворк. не знаю к чему он там подталкивет, но создавать методы контроллеров можно как хочешь. Я работаю с симфони и там тоже хватает всяких генераторов, но никуда они не подталкивают

А get /пирожки — просто HTTP-запрос.

А get /пирожки — просто HTTP-запрос.

всё, что работает поверх HTTP - это какой-нибудь запрос )

всё, что работает поверх HTTP - это какой-нибудь запрос )

Ну, в общем, да.

v, ты троллишь людей, вместо того, чтобы объяснить что "вот REST удобно применять там-то там-то, а вот там-то там-то применять херово"

Ща буду кофе с пирожками пить

@Folleah GET /пирожки

v, ты троллишь людей, вместо того, чтобы объяснить что "вот REST удобно применять там-то там-то, а вот там-то там-то применять херово"

а чего им объяснять, они и так лучше меня все знают. Только объяснить не могут. Как та собачка :D

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

йеп. Не обязано

а чего им объяснять, они и так лучше меня все знают. Только объяснить не могут. Как та собачка :D

Ты ведёшь полемику ради полемики. Таким образом ты пытаешься самоутвердиться. Это и осуждается здесь. Можешь не оправдываться.

Ты ведёшь полемику ради полемики. Таким образом ты пытаешься самоутвердиться. Это и осуждается здесь. Можешь не оправдываться.

+ 1

Ты ведёшь полемику ради полемики. Таким образом ты пытаешься самоутвердиться. Это и осуждается здесь. Можешь не оправдываться.

Ты слишком хорошо думаешь о дураках

а чего им объяснять, они и так лучше меня все знают. Только объяснить не могут. Как та собачка :D

Вот херовый из тебя сеньиор выйдет с таким подходом.

Ты слишком хорошо думаешь о дураках

Иногда случается такая слабость.

Вот херовый из тебя сеньиор выйдет с таким подходом.

Он ещё в школе.

Он ещё в школе.

одно другому не мешает

Ты ведёшь полемику ради полемики. Таким образом ты пытаешься самоутвердиться. Это и осуждается здесь. Можешь не оправдываться.

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

Вот херовый из тебя сеньиор выйдет с таким подходом.

Я не гожусь на сеньора. Я всех поубиваю

Ты слишком хорошо думаешь о дураках

Иногда случается такая слабость.

петушка хвалит кукуха

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

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

ERROR: S client not available

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

какую проблему?

где проблема?

какую проблему?

пробел, очепятка

пф

на пробел в познаниях

им и так хорошо :d

тут все сложившиеся php-разработчики

тут все сложившиеся php-разработчики

хз, никто себя таким не называл

со своим мнением о том, что такое restful-архитектура

и почему get /пирожки не может к таковой относиться

Эх последняя такая война в группе была, когда парни обсуждали чтотако MVC)

а все почему

потому что нет конкретики

Потому что get /пирожки не обязано быть пирожками. Не важно, в каком формате, но в ответ должен прийти список прирожков.

А get /пирожки — просто HTTP-запрос.

Эх последняя такая война в группе была, когда парни обсуждали чтотако MVC)

кстати, там тоже кого-нибудь забанить просили за неверную трактовку?

А get /пирожки — просто HTTP-запрос.

зайка, ты же хотел, чтобы я от тебя отстал

а все почему

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

тебе горящая попка покоя не дает?

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

и обычно все это обсасывание теории очень бесит =)

потому что у него свое мнение, а у тебя свое

со своим мнением о том, что такое restful-архитектура

вообще, насколько мне известно, никакого "стандарта" вроде нет еще.

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

зато мне привели. get /пирожки - не рестфул, и все

но что-то товарищ из Казахстана отмалчивается, почему

зато мне привели. get /пирожки - не рестфул, и все

ну бля, ты же не сказал, что твои get /пирожки возвращают

надо и это было описать

v, ты просто тролишь людей

кстати, там тоже кого-нибудь забанить просили за неверную трактовку?

Здесь никого не просили забанить. =) Я просто предположил, что ты баклан. Ой. Не предположил. Но о том, что тебя следует забанить, я предположил. Т.к. возможно (ну, есть очень небольшая вероятность — Folleah знает), что ты тролль.

и тогда уже можно было бы тереть рестфул или нет

ну бля, ты же не сказал, что твои get /пирожки возвращают

это был пример для товарища из Казахстана. Он сказал, что не рестфул, потому что post, put и т.д. не используются

но что-то товарищ из Казахстана отмалчивается, почему

арбайтын я