Нужно ли возвращать ошибку из rest api?

Question

[WebDev]

Делаю метод, который отправляет приглашение пользователю, но в методе есть проверки, при которых приглашение не будет отправлено. Нужно ли в случае, если проверка не прошла, выбрасывать ошибку или правильнее отправлять текст с ошибкой и статусом 200?

public function invite()
{
    $email = request()->input('email');

    $user = User::where('email', $email)->first();

    if ($user->isCustomer) {
        abort(403);
    }

    //отправляем приглашение
}

В коде проверка, не является ли пользователь покупателем, но ошибкой ведь это не является.
То есть я мог бы вместо abort(403) возвращать статус 200 с телом ответа, например:

if ($user->isCustomer) {
    return response()->json(['status' => 'error']);
} else {
    return response()->json(['status' => 'ok']);
}

Принимать на клиенте и парсить ответ.
Как правильно?

Comments

[Евгений Ромашкан]

Из REST api нужно возвращать гипертекст который сможет понять и отобразить клиент.
Но у вас не REST а RPC, потому возвращать можно то, что удобнее. Обычно нет смысла маппить бесконечное число различных ошибок предметной области на пару десятков HTTP заголовков

[Mikhail Osher]

$user = User::where('email', $email)->first() может вернуть null

[WebDev]

Mikhail Osher, Я код для примера на тостере упростил. У себя в это проверяю.

[Alex Wells]

Евгений Ромашкан, что? Из рест апи нужно возвращать гипертекст? АПИ - само по себе подразумевает, что никакого гипертекста там и БЛИЗКО быть не должно, нигде.

[Евгений Ромашкан]

Alex Wells, С чего вдруг?)
Гипертекст это основа REST API, и Рой Филдинг уже писал что разочерован тем что термином некоторые кличут теперь все подряд http апишки - roy.gbiv.com/untangled/2008/rest-apis-must-be-hype...

p.s.Ну и, первоисточник - "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state"(с) https://www.ics.uci.edu/~fielding/pubs/dissertatio... пункт 5.1.5, ограничение "Unified Interface"

[Alex Wells]

Евгений Ромашкан, можем так же сказать, что HTTP (Hyper Text чето там) тоже должен только html отдавать, потому что.. это в названии? Какая разница, что туда заложил автор, если используется оно совсем не по значению? Оф. страница вики по "HTTP Api" скажет, что основными методами общения являются XML и JSON. Любой бекендер, услышав "api", подумает о каком-то интерфейсе общения (причем не в рамках http), который не привязан к UI (чем является html). Посему независимо от того, что там хотел автор, термин "api" априори означает другое, да и пытатся переубедить всех программистов в мире что "rest api" должен юзать html - глупо.

[Евгений Ромашкан]

Alex Wells, "Смешались в кучу кони, люди", вы вообще видите разницу между терминами "API". "REST API", "HTTP API"?

Оф. страница вики по "HTTP Api"

На вики нет страницы с названием "HTTP API"

можем так же сказать, что HTTP (Hyper Text чето там) тоже должен только html отдавать, потому что.. это в названии?

Http это в первую очередь протокол, через него можно передавать не только гипертекст, аналогия некорректна.

[Alex Wells]

Евгений Ромашкан,

На вики нет страницы с названием "HTTP API"

Web API. Роли не играет.

Http это в первую очередь протокол, через него можно передавать не только гипертекст, аналогия некорректна.

Твоя аргументация - некорректна. Это протокол, и что дальше? Само по себе это не является аргументом. Равно как и то, что через него можно передавать не только гипертекст - как и с апи.

вы вообще видите разницу между терминами "API". "REST API", "HTTP API"?

Вижу. А самое главное я вижу сходство - API.

[Евгений Ромашкан]

Alex Wells, Ок. То есть, я пишу что в REST API нужно возвращать гипертекст, а вы мне даёте ссылку на Web API. Вопрос - как это относится к текущей теме и почему это должно якобы опровергать мои слова?
Если вы зайдёте на страничку REST API в Вики там в первую очередь будет указан HTML.

Это протокол, и что дальше? Само по себе это не является аргументом. Равно как и то, что через него можно передавать не только гипертекст - как и с апи

Да, через API можно передавать любую информацию не только гипертекст, разве я где-то говорил обратное? Или вы опровергаете собой же выдуманные тезисы?

REST это набор архитектурных ограничений при проектировании клиент-серверных приложений. Если вы назовёте RPC API "REST", оно им не станет само по себе. Если вы будете через http протокол передавать не гипертекст, протокол http им же и останется.

[Alex Wells]

Евгений Ромашкан,

как это относится к текущей теме

REST API это subset web API. Любое rest api является web api.

Или вы опровергаете собой же выдуманные тезисы?

Я говорю, что аргумент бессмыслен.

И да, говорил.

Из REST api нужно возвращать гипертекст который сможет понять и отобразить клиент.

[Евгений Ромашкан]

Alex Wells,

REST API это subset web API. Любое rest api является web api.

Спасибо Кэп, дальше то что? Большинство WEB API возвращают json и xml, я с этим не спорил, в чем вы меня хотите убедить тогда?

И да, говорил.

Если вы не видите разницы между нижеприведёнными фразами, я не намерен далее пытаться с вами спорить

Из REST api нужно возвращать гипертекст

через API можно передавать любую информацию не только гипертекст

[Alex Wells]

Спасибо Кэп, дальше то что?

В том, что это прямо относится к текущей теме. Неужели так сложно прочесть свое же предложение, на которое я ответил?

Если вы не видите разницы между нижеприведёнными фразами, я не намерен далее пытаться с вами спорить

Равно как и я, если ты не знаешь значения слова "нужно".

Answer 1

[Иван Жук]

По идее, код 403 Forbidden тут подходит, ведь использование этого метода запрещено пользователю с определенной ролью. Ну и чтобы было понятно в почему ответ 403, можно сделать так:

return response()->json(['error' => 'Forbidden for current user role.'], 403);

Ну или 422 Unprocessable Entity можно отправлять, если проверка идет не роли пользователя, который отправляет запрос, а роли пользователя, которому отправляют инвайт. Тогда по сути это ошибка валидации:

return response()->json(['error' => 'The required user is a customer.'], 422);

Comments

[Евгений Ромашкан]

Проще статус 200 вернуть и избавиться от лишней зависимости и необходимости разные ошибки на одни и те же http коды которых и так пара десятков

[Александр Гамов]

Евгений Ромашкан, да вообще оставить только 200ый код, а остальное в ответе отдавать (сарказм).

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

[DTX]

Александр Гамов, а при чем тут исключения? Их можно благополучно использовать, написав какую-нибудь стандартную функцию-обертку, и потом выдавать 200 и ['isSuccess' => 'True/False', ...]

[WebDev]

DTX, ну это же костыль. Для этого и придумали коды http, чтобы на них и ориентироваться, а не на isSuccess.

[DTX]

WebDev, я не говорю, что так правильно. Но так может быть удобнее и проще) Для прототипирования, например, чтобы меня сильно не пинали)

[Евгений Ромашкан]

WebDev, Костыль это пытаться все ошибки приложения описать парой десятков http кодов.
Если для вас важно не удобство API, то я даже не знаю что.

Answer 2

[Alex Wells]

403 отношения к этому не имеет. 403 относится к юзеру, который делает реквест.

Это ошибка. 200 значит, что ВСЕ прошло успешно, чего в вашем случае не произошло.

Бросайте 412 или 422 - не надо придумывать велосипед. И никаких status тоже не нужно.

Answer 3

[Одиночка Айс]

Ошибки бывают 2 видов: серверные и клиентские. Если вы получили серверную (404, 500, etc), отдавайте общее сообщение о том, что "Что-то пошло не так". Если ошибка клиентская (пользователь не найден, у пользователя не те права), отдавайте свои сообщения под каждый случай. Конечный пользователь должен наглядно видеть что он делает не так, а не эти ваши заумности в коде.