Спасибо за отличный материал, а так же за, казалось бы, очевидную идею про отрывание заголовков. Этак тушки изображений можно хранить в облаках чуть ли не открыто, а заголовки где-то в базе.
Слушайте, ребята, хочу просто сказать спасибо JetBrains за такие супер офигительные инструменты. Мы не успеваем освоить новые фичи как завозят новые. Спасибо большучее!
В ответе вдруг пришло 2 пользователя, кого логинить?
Уточнять. Например я могу быть зарегистрирован как исполнитель и как заказчик, и иметь один email. Спросите меня в качестве кого я хочу войти. А если такого не предусмотрено, то двойных емейлов в базе быть не должно. Еще на этапе регистрации или смены это нужно отсекать.
Да и просто если в коде возвращать массив там где должен быть объект, то это считается неправильным, почему в API должно быть по-другому.
Если мы идем на /search — то ответ подразумевает наличие нескольких элементов.
Если же это логин, то тут должно быть что-то, типа:
POST /api/users/authorizations {field:email, data:'user@example.com'}
хотя если в базе два юзера с одним мылом, вопрос кого логинить остается открытым :-)
Тут можно сразу спросить ошибка чего? Ошибка веб сервера? Ошибка разработчика? Или ответ приложения?
А какая разница? Мне как серверу, который работает с вашим api совершенно до лампочки кто мне ответил кодом 404: прокси, web-server, приложение, еще много кто может прислать мне 404. Мне как серверу понятно — Здесь рыбы нет.
Если просто нет контента, это не ошибка, это нормальная ситуация. Поэтому код 404 Not Found это тоже не ошибка, это нормальная ситуация, и разруливаем мы ее одинаково.
Ну это тогда получается нелогично, не соответствует модели данных. Email однозначно идентифицирует пользвателя, а в ответе всегда будет массив.
Однозначно идентифицирует пользователя ID — это первичный уникальный ключ. А email в таком случае опциональный идентификатор, и никто не запрещает иметь многим пользователям один email, ну чисто теоретически. Поэтому на выходе и будет массив, все логично, я считаю.
Мы сделали что-то вроде GET /api/hash/{hash}/discount
На мой взгляд это чуть чуть неверно, ибо вы просто достаете сущность hash по его параметру {hash}, пользователя тут нет.
Мне кажется прикольнее было бы так
GET /api/users/{id}/hashes/{hash}/discounts
То есть получается так.
RPC:
Один эндпойнт POST /api/tikets/{id}/activate, с конкретными действиями в обработчике.
…
REST:
4 возможных эндпойнта для глаголов GET/POST/PUT/DELETE.
…
Все так :-) ну а как? Главное не перемешивать оба этих подхода, а то начинаем за REST, а опоминаемся дописывая глаголы к эндпоинту )))
ну например так, создаем ресурс Поиск. И добавляем новую сущность в ресурс поиска (создаем элемент поиска). На человеческом языке это звучит как «создай мне поиск пользователей с вот такими вот данными»
POST /api/users/search { field: 'email', value: 'user@example.com'}
либо просто отдельный ресурс поиск, и искать сущность и поле тогда можно например так
GET /api/search/users?email=user@example.com
Если я правильно понял задачу то (достать у пользователя {id} сущности по хешу {hash}):
GET /api/users/{id}/entities/{hash}
можно добавить билетам связнную сущность статус билета и крутить автивации например так:
POST /api/tikets/{id}/status { isActive: true, date: now}
заодно можно историю активаций смотреть, и деактивировать после активации
Спасибо вам за статью. После срача в прошлой статье меня тоже подрывало написать подобную, вы опередили.
Я своим студентам коды ответов на первой же лекции давал, и очень настоятельно требовал их разумно использовать. Теперь у них в головах недоумение по поводу 200 ОК error:true.
А у более опытных обычно срабатывает внутренний демон, если начинаешь колхозить нестандартное на стандартном — значит где-то косяк в архитектуре.
REST вообще очень легко начать использовать не правильно. Начиная от глаголов в урлах, и get запросов на добавление сущности, заканчивая 200 Ок ( все нормально, падаем! )
Ios приложение, в принципе это действительно наши проблемы, но хотелось бы чтобы и о нас позаботились :-) напишу разработчикам приложения, может поправят
А можно вас попросить вставить значки возведения в степень? А то читаешь 2341 и не понимаешь что это 23^41, а это разница в 41 порядок, что действительно очень много.
Мысль, как говорится, поперла :-)))
Уточнять. Например я могу быть зарегистрирован как исполнитель и как заказчик, и иметь один email. Спросите меня в качестве кого я хочу войти. А если такого не предусмотрено, то двойных емейлов в базе быть не должно. Еще на этапе регистрации или смены это нужно отсекать.
Если мы идем на /search — то ответ подразумевает наличие нескольких элементов.
Если же это логин, то тут должно быть что-то, типа:
хотя если в базе два юзера с одним мылом, вопрос кого логинить остается открытым :-)
А какая разница? Мне как серверу, который работает с вашим api совершенно до лампочки кто мне ответил кодом 404: прокси, web-server, приложение, еще много кто может прислать мне 404. Мне как серверу понятно — Здесь рыбы нет.
Однозначно идентифицирует пользователя ID — это первичный уникальный ключ. А email в таком случае опциональный идентификатор, и никто не запрещает иметь многим пользователям один email, ну чисто теоретически. Поэтому на выходе и будет массив, все логично, я считаю.
На мой взгляд это чуть чуть неверно, ибо вы просто достаете сущность hash по его параметру {hash}, пользователя тут нет.
Мне кажется прикольнее было бы так
Все так :-) ну а как? Главное не перемешивать оба этих подхода, а то начинаем за REST, а опоминаемся дописывая глаголы к эндпоинту )))
либо просто отдельный ресурс поиск, и искать сущность и поле тогда можно например так
Я своим студентам коды ответов на первой же лекции давал, и очень настоятельно требовал их разумно использовать. Теперь у них в головах недоумение по поводу 200 ОК error:true.
А у более опытных обычно срабатывает внутренний демон, если начинаешь колхозить нестандартное на стандартном — значит где-то косяк в архитектуре.
REST вообще очень легко начать использовать не правильно. Начиная от глаголов в урлах, и get запросов на добавление сущности, заканчивая 200 Ок ( все нормально, падаем! )
Это прям взгляд на тренд будущего — дизайн не нужен, нужен функционал и быстрый доступ. Например голосовое управление.
Кнопку «купить» нужно постараться найти, это соревнование, это приз за настойчивость, кнопка «купить» не должна сама меня найти.
Как то так :-)