Здравствуйте, vaa, Вы писали:
vaa>Вот зачем? vaa>Ну сделайте отдельный метод.
Это не вписывается в REST и может быть проблемно для клиентов, если клиенты ожидают REST. С другой стороны, REST — это не Библия и не Талмуд, писать нужно как лучше для системы, а не как советуют в книжках.
Re: rest один метод возвращает разные типы. Зачем?
Здравствуйте, Reset, Вы писали:
vaa>>Вот зачем?
R>Вот именно зачем?
R>Зачем задавать этот вопрос здесь? Почему бы не задать его там? Тем, кто написал такую реализацию...
Мало ли, может и тут есть кто-то практикующий подобное.
В моем случае прямой связи нет к сожалению, только документация.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re: rest один метод возвращает разные типы. Зачем?
Здравствуйте, vaa, Вы писали:
vaa>Вот зачем? vaa>Ну сделайте отдельный метод.
Не от большого ума Меня вот всегда удивляет поле "status", типа коды ответа HTTP для динозавров, а вот настоящие хипсторы должны так обрабатывать ошибки.
Re: rest один метод возвращает разные типы. Зачем?
vaa>Вот зачем? vaa>Ну сделайте отдельный метод.
Не очень понятно, зачем делать отдельный метод.
Сделайте 2 метода на своей стороне, устроенные по-своему.
Вам было бы легче, если бы URL второго запроса был устроен как GET /items/alice?
С т.з. REST никакой разницы между этими случаями нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: rest один метод возвращает разные типы. Зачем?
Здравствуйте, cppguard, Вы писали:
C>Не от большого ума Меня вот всегда удивляет поле "status", типа коды ответа HTTP для динозавров, а вот настоящие хипсторы должны так обрабатывать ошибки.
Эээ... Ну вернул я 400 Bad Request, почему бы в статусе не описать что конкретно не понравилось?
Спасибо за внимание
Re[3]: rest один метод возвращает разные типы. Зачем?
Здравствуйте, Doom100500, Вы писали:
D>Здравствуйте, cppguard, Вы писали:
C>>Не от большого ума Меня вот всегда удивляет поле "status", типа коды ответа HTTP для динозавров, а вот настоящие хипсторы должны так обрабатывать ошибки.
D>Эээ... Ну вернул я 400 Bad Request, почему бы в статусе не описать что конкретно не понравилось?
Так кто же мешает? Я же говорю про случаи, когда ошибка возвращается как HTTP 200. Или добавлен ресурс, а вместо 201 Created и, как положено, ссылки на ресурс в заголовке, всё пихают в json.
Re[2]: rest один метод возвращает разные типы. Зачем?
Здравствуйте, cppguard, Вы писали:
C>Не от большого ума Меня вот всегда удивляет поле "status", типа коды ответа HTTP для динозавров, а вот настоящие хипсторы должны так обрабатывать ошибки.
Поле status немного упрощает разработку на клиенте — хидеры не всегда протаскиваются до обрабатывающего кода. Ну и есть еще любители альтернативных HTTP протоколов, где хидера может и не быть.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: rest один метод возвращает разные типы. Зачем?
Конкретно здесь похоже на какой то косяк. Но, в целом, никакого криминала в изменении формата в зависимости от параметров нет, для REST это нормально. Классический вариант, в дотнете вообще автоматически поддерживаемый — менять формат вывода в зависимости от хидера Accept-Encoding.
vaa>Ну сделайте отдельный метод.
Не метод, а ресурс. И в данном конкретном случае не очень похоже на разные ресурсы, не правда ли?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: rest один метод возвращает разные типы. Зачем?
Здравствуйте, Sinclair, Вы писали:
S>Вам было бы легче, если бы URL второго запроса был устроен как GET /items/alice?
Было бы легче. Ресурс часто определяется именно как путь + метод. Во-первых, в инструментарии (схемы типа OpenAPI и т.п. и генерация кода на их основе, в настройке роутинга в серверных фреймворках). Во-вторых, в голове пользователя api, пытающегося воссоздать схему методом тыка и не ожидающего, что добавление query параметров меняет формат результата (кроме очевидных случаев типа ?format=xml или параметров влияющих на включение опциональных полей).
S>С т.з. REST никакой разницы между этими случаями нет.
Есть ожидания (как минимум мои) "по умолчанию" от REST. Не в том смысле, что REST должен именно так работать, а в том смысле, что когда видишь API без описания, то ожидаешь такого поведения с большей вероятностью, чем другого. Никто не обязан делать именно так, но приятнее, когда ожидания оправдываются.
Если имя уникально, то /items/alice это ресурс, от которого можно ожидать поддержки глаголов GET, PUT, DELETE и 404 при отсутствии сущности.
/items?name=alice на первый взгляд воспринимается как поиск (особенно если уникальность имени в системе вызывает сомнения). От поиска ожидаешь возврата отфильтрованной коллекции (в том числе пустой коллекции вместо 404 при отсутствии результата). Также с этой точки зрения PUT|DELETE /items?name=alice выглядит совсем уж странно.
Но пусть /items?name=alice реализован как сейчас, имя уникально. Тогда метод все равно должен возвращать 404 при отсутствии alice (или что?). Нам нужно дополнить api возможностью поиска, и в духе текущего подхода мы добавляем поддержку параметра /items?search=ali. Ищем по подстроке. Этот метод уже должен возвращать коллекцию ({ count = 3, items = [ {}, {}, {}] }), и не возвращать 404. Выглядит похоже, а поведение совсем разное, ошибиться недолго.
(И как в этом случае должен вести себя запрос /items?name=alice&search=ali ?)
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Конкретно здесь похоже на какой то косяк. Но, в целом, никакого криминала в изменении формата в зависимости от параметров нет, для REST это нормально. Классический вариант, в дотнете вообще автоматически поддерживаемый — менять формат вывода в зависимости от хидера Accept-Encoding.
Encoding — это способ кодирования — как сериализовать структуру данных в виде байтиков. А вот возвращать разную структуру данных в зависимости от параметров — это грабли на пустом месте.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: rest один метод возвращает разные типы. Зачем?
Ну кто-то так спроектировал. Или просто так сложилось.
vaa>Ну сделайте отдельный метод.
Да, лучше было бы возвращать одинаковый тип — в обоих случаях массив структур (пусть и одну, удовлетворяющую условию).
Либо сделать отдельный метод /item?name=alice возвращающий одну структуру.
Best regards, Буравчик
Re[2]: rest один метод возвращает разные типы. Зачем?
Подобные вещи делаются для пагинации: { items: [] , total: 0, hasMore: false }
Надо просто приводить к одному наиболее общему формату ответа независимо от параметров.
Re[2]: rest один метод возвращает разные типы. Зачем?
Меня вот всегда удивляет поле "status", типа коды ответа HTTP для динозавров, а вот настоящие хипсторы должны так обрабатывать ошибки.
