Подскажите best practise, в апи надо сделать возможность получать запись и по айдишнику и по slug/alias, как лучше сделать? Один метод и внутри разруливать? Или разные методы?

Я бы разные методы сделал. С целью изоляции логики

Непредсказуемый поиск мне кажется опасным

Это уже не получени записи тогда, а поиск записи по ID. Тогда да, тогда можно смешать. Проще говоря, если GET /api/row/12 | GET /api/row/vasya - будет несколько непредсказуемо. Если POST /api/row/find - будет понятно что ищешь по каким либо данным запись.

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

я бы в атрибут хттп вынес такое

типо ?search=blahblahblah

соответственно есть один метод, который при наличии ид - выдает конкретную запись, а если айди нет - пытается искать по тому, что есть в search

типо ?search=blahblahblah

названия чего?

ну slug

Ааа. Ну его да. С id иная ситуация. Его в uri милое дело засунуть :)

то есть ?id=123&search=blahblahblah будет в первую очередь пытаться найти по айди и если не нашел то искать по слагу?

ага

ну типо ты указал конкретный ид

model/{id} а так?

то есть model/123?search=ewrwevcwrvb

можно усовершенствовать следующим образом: GET /api/row/find?id=1&slug=anya

то есть model/123?search=ewrwevcwrvb

Как ты это документировать будешь?

то есть model/123?search=ewrwevcwrvb

ну я именно это и подразумевал)

Плохая идея

Как ты это документировать будешь?

обычно же

Плохая идея

а какая хорошая?

ну то есть запись получить по id, Необязательный доп параметр поиск по slug

А если id не знаешь?

а какая хорошая?

Ну например разные роуты на взятие по id и поиск. resources/{resource} resources?search=...

Ну например разные роуты на взятие по id и поиск. resources/{resource} resources?search=...

+1

а поиск по слагу только?

мне только по слагу надо. может тогда и назвать не search?

мне только по слагу надо. может тогда и назвать не search?

Ну тогда resources/{resource} resources?slug=...

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

SELECT count(*) as kolvo, avg(rating) FROM golosa

SELECT count(*) as kolvo, avg(rating) FROM golosa

А как-то средставми Eloquent можно ?

Тебе нужны selectRaw pluck и постобработка небольшой полученной коллекции

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

https://ru.wikipedia.org/wiki/REST Глянь здесь Пдробно написаны приципы API. (Может и читал, я фиг знает ? ) В ларе они реализуемы

Тебе нужны selectRaw pluck и постобработка небольшой полученной коллекции

а как-то чуть подробнее можно? То я пока не совсем представляю

а как-то чуть подробнее можно? То я пока не совсем представляю

https://laravel.ru/forum/viewtopic.php?id=2694

Первое что нашел

а как делать версию апи? например делаю группу роутов v1, там все методы описываю. Потом делаю группу роутов v2, и например если метод отсутствует то искать в v1?

чтоб описывать только изменившиеся методы

а как-то чуть подробнее можно? То я пока не совсем представляю

Rewiev::selectRaw('count(score) as cnt, score')->groupBy('score')->pluck('cnt', 'score')

а как делать версию апи? например делаю группу роутов v1, там все методы описываю. Потом делаю группу роутов v2, и например если метод отсутствует то искать в v1?

Чето как-то ты глубоко зашел. Тогда на каждый узел у тебя должен быть url. Я такой доки не знаю. Если кто занет скинье. Буду юзать

Rewiev::selectRaw('count(score) as cnt, score')->groupBy('score')->pluck('cnt', 'score')

а AVG, как сюда еще добавить ?

да, далековато) пока сделаю базовые методы

а AVG, как сюда еще добавить ?

Это уже у полученной коллекции бери

Я с телефона так что код тяжело писать)

Кто инглиш сносно знает?

https://github.com/DarkaOnLine/L5-Swagger Это не автодокументатор?

Кто инглиш сносно знает?

Говори

Раз вопрос поднялся на тему Lara api+swagger - поискал в инете. Вроде похоже на автодок

https://github.com/DarkaOnLine/L5-Swagger Это не автодокументатор?

о нём много статей с примерами

да, автодок на сколько я понял

Это обёртка над swagger-php

честно говоря, сваггер такое говно

и доку писать под него в коде - отдельное удовольствие

просто описание метода в 10 раз больше самого метода

это не норма

Там вроде uml или аннотации?

аннотации

это не норма

Так у всех у них так в 10 раз больше метода

можно yml чо уж

о нём много статей с примерами

Скажем так: у меня api строго типизированный начиная от принимаемых данных, заканчивая ответом. Все это я пакую в json сваггера и генерю на стороне. Это может автоматизировать процесс публикации доки на 100%?

Так у всех у них так в 10 раз больше метода

хочу под ларку конкретно написать автогенератор доки

И вообще метод это не только строчка вызова в контроллере. За ним может таиться и 500 строк )

Внутри каких нибудь моделей или сервисов

это понятное дело

но все равно

сваггер чересчур тяжеловесный

Уж лучше свагер схемму а не аннотации в коде

У нас было так, к каждому контроллеру интерфейс и там уже эти долбанные аннотации. Мне не понравилось.

мне кажется можно генерить документацию чисто по описанию + ответу метода

да даж не кажется, а факт)

остается запилить только

работать конечно будет только в ларке

У нас было так, к каждому контроллеру интерфейс и там уже эти долбанные аннотации. Мне не понравилось.

О а про интерфейсы я не подумал. Звучит вроде же неплохо. Почему не зашло?

работать конечно будет только в ларке

есть решение, но не публиковал

Да там такая огромная аннотация постоянно

Дело не в интерфейсе

Но другого даже не использовал

есть решение, но не публиковал

Гемррой в том что там строгая типизация и это создает бюрократию. А я замучюсь объяснять почему нужны коллекции для исходящих данных и почему нужно описывать каждую ошибку. А также ошжидаемые данные

А чего, больше вообще инструментов нет?

Дело не в интерфейсе

Ну благодаря ему ты отделяешь аннотации от нужного кода с его докблоком и при этом сохраняешь тему с частью информации в сингнатуре метода

Гемррой в том что там строгая типизация и это создает бюрократию. А я замучюсь объяснять почему нужны коллекции для исходящих данных и почему нужно описывать каждую ошибку. А также ошжидаемые данные

почему нужны коллекции?)

Ну благодаря ему ты отделяешь аннотации от нужного кода с его докблоком и при этом сохраняешь тему с частью информации в сингнатуре метода

Не ну я согласен что это лучше )))

Вот базис API и это блин все критично

Зато и автотесты можно гонять

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

Да и вообще как бы логично получается через интерфейс.

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

Тесты окупятся если есть время их писать

Там автогенерация тестов ?

Да и вообще как бы логично получается через интерфейс.

Это так просто но мне в голову не пришло)) я в свое время тупо ямл схемму выбрал

Был на проекте где задачу без тестов возвращают и ниибет

Может блин оформить и опубликовать...

Может блин оформить и опубликовать...

Поддержите консультацией и пулл ревестами?

У меня вообще зенд 2 щас (