угу

Круто. Спасибо. )

мне у них дико нравится визуализация алгоритмов

Для питона есть еще вот такое, почти для гуманитариев: http://aliev.me/runestone/

Народ, стоит ли для REST юзать для каждого метода свой тип запроса (GET, PUT, POST, DELETE)? Или можно одним POST обойтись?

ну или POST и GET

Конечно можно.

Да я знаю что можно)

Но с точки зрения реализации, как правильней?

Так это же стиль, а не паттерн(протокол). Можно как угодно) Главное чтобы удобно было.

Ну я так думаю во всяком случае.

Народ, стоит ли для REST юзать для каждого метода свой тип запроса (GET, PUT, POST, DELETE)? Или можно одним POST обойтись?

а в чем проблемы?

Но с точки зрения реализации, как правильней?

KISS

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

если ты будешь юзать только POST

у тебя выйдет PRC

с методами вида

POST /addSomething POST /removeSomething?id=1

если бы мне как мобильщику/фронтэндщику дали такую апишку...

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

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

придется ваять велосипед

в итоге KISS не соблюдаем. Интерфейс взаимодействия выходит сложным

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

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

меньше велосипедов - выше портируемость

Рест подразумевает разные типы запросов

Рест подразумевает разные типы запросов

это скорее к рестфул...

Рест подразумевает разные типы запросов

не совсем. Конкретно rest подразумевает: - ресурсы можно идентифицировать (в HTTP для этого URI) - с ресурсами мы работаем при помощи их представления (в HTTP это заголовки + тело + verb) - чето там еще - HATEOAS

это скорее к рестфул...

а в чем разница?)

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

чуваки, которые будут пилить клиент - это мои клиенты)

такая тавтология

такая тавтология

короч. Если "твои клиенты" сидят не рядом с тобой - делай нормальную апишку

почему ты не хочешь юзать PUT/DELETE?

Потому что это сложно для понимания

нужно как можно более простое апи сделать

Норм

Потому что это сложно для понимания

для тебя или для тех кто будет клиент писать?)

Делит - удаляем

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md#74-supported-methods

для тебя или для тех кто будет клиент писать?)

для тех кто будет клиент писать

Делит - удаляем

PUT - создаем именованные ресурсы или заменяем, POST - все остальное

им не надо вот это вот типы запросов и т.д.

для тех кто будет клиент писать

почему ты так думаешь?)

Гет получаем

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

Это не рест знач

Гет получаем

все намного проще - надо просто выучить слово "идемпотентность"

Это не рест знач

и в этом нет ничего плохого. Почти никто rest не делает полноценный

Я знаю это слово оно к пост и пут

почему ты так думаешь?)

Потому что добавление методов для запроса усложнит сам запрос

Относится

Потому что добавление методов для запроса усложнит сам запрос

эм.... нет)

Да

Нет)

это куда неочевиднее

пруф

это куда неочевиднее

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

им не надо вот это вот типы запросов и т.д.

Блин, не делай так. Реально. Я с одиними тоже работал. 2 разраба андроид. Они меня заставили сделать им из REST подобие JSON-RPC это была боль))

это куда неочевиднее

просто приведи объективные причины по которым ты считаешь что "им это сложна"

возьми какой apiary, накидай им доку

и пусть балуются

там даже кодогенерация с примерами есть

Я делаю апи для людей, а не для внутренней разработки

Даже у апи фейсбука работа с апи ограничена GET и POST

Даже у апи фейсбука работа с апи ограничена GET и POST

вообще-то нет)

да

хотя да

ERROR: S client not available

нашел с delete

ну ладно, буду делать так значит

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md#74-supported-methods

может поможет тебе делать норм апишки

только не юзай patch

лучше post вместо него

его нет в стандарте HTTP и незачем его тянуть

@F01134H А на чём будешь писать API ? Фреймворк ?

Спасибо)

@F01134H А на чём будешь писать API ? Фреймворк ?

laravel

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

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

может не надо?

юзай готовое

не

Мож сразу на голом пшп

На асме

у лары из коробки хорошая работа с рест апи.

называется symfony/routing)

да

и я не вижу причин что то лишнее туда пихать

там даже с типами запроса работать просто

Может сам будешь ловить тсп пакеты и передавать инструкции процессору

и я не вижу причин что то лишнее туда пихать

ну там всякие фракталы.... хотя от размера api зависит

сколько ресурсов будет

пока что

вся апишка - 4 метода)

аа... а апишка тупо на хранение инфы?

и даже в далекой перспективе вырастет наверное максимум до 20

я бы поленился даже апишку писать и сказал бы юзать firebase... но может быть в твоем случае не подойдет. слишком мало деталей

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

ясненько

Я вот, на yii2 решил писать своё API. API для таксопарка, учет топлива и так далее. Полная ж. Не советую Yii2 для REST кароче.