Petro123fkthat,
Странное обсуждаем.
404 это исключительная ситуация. Это exe вызывает dll, а метода давно нету.
Чо? Какое ДЛЛ, какое ЕКЗЕ. Вбил криворукий руками урл в адресной строке несуществующий - что же тут исключительного.

PinkCatfkthat,

Вбил криворукий руками урл в адресной строке несуществующий
-----
Не-не, не так - вот сервис сформировал урлу и получил... 404.
Всегда было - данные, а сегодня - 404...
А всего-то тупорылый админ перересайзил пулл динамических ипов...

Тогда вообще будет иксепшен - не будет ни 404 ни 100500. Потому что не будет коннекта к серверу.

Вообще, если это так нужно, то всегда можно в боди ответа 404 писать что угодно в любом формате. Это полностью в рамках рфц.

Petro123Урл в веб это поолный аналог названий методов с параметрами после знака вопроса. Веб API.

Нет, скорее, урл - это ид некоторой сущности, или коллекции сущностей, а параметры запроса - некоторые опции представления этой сущности или коллекции. Так более по РЕСТ. А то, что вы описали - это чисто РПЦ подход, что диаметрально.

Petro123,

РЕСТ он и хорош, что очень простой и интуитивно понятный. В тех же статусах ответа, например:

GET /orders/4269?blabla=bla

200 - все ок - получай, смотри
404 - заказа 4269 вообще в природе нет
403 - заказ такой есть, но хрен тебе можно его смотреть
400 - вроде все нормально, но, ты, чувак, после вопроса какую-то херню написал.

Petro123fkthatпараметры запроса - некоторые опции представления этой сущности или коллекции.кстати, на POST какое там представление View? Как раз таки методы).

POST - cоздание новой сущности-ресурса, представление (данные) которого при этом передаются в теле запроса. Аналогично PUT (PATCH) - обновление ресурса, соответствующего урлу запроса данными из тела запроса, DELETE - удаление ресурса, e.g. DELETE /orders/4269

Petro123,

В общем-то достаточно общая тема, когда реально нужен РПЦ, но хочеться чистый РЕСТ, но, в принципе, можно решить просто как бы начав думать немного по-другому, типа, что "все что угодно есть ресурс" и рассматривать сам вызов команды, как ресурс. Например:

POST /rpc
Content-type: application/json

{
"command": "MoneyTransfer",
"params": {
"from": "bla-bla",
"to": "bla-bla-bla",
"amount": 100500
}
}

Тут вопрос просто в том, насколько хочется оставаться в рамках "чистого РЕСТ".

Petro123fkthatPOST - cоздание новой сущности-ресурса,убери слово сущность и будет как у меня - это команды серверу или методы)))
Удачи!

Вот блин, ну нет в РЕСТе такого как "команда серверу или метод". Вот, смотри, если провести параллель с БД, то, вот, вызов хранимки - это РПЦ , а СRUD - это РЕСТ. Вот, посоветую книгу, хотя она немного старенькая, т.ч. её по дигонали читать стоит, но, стоящая, тем не менее: https://goo.gl/SCjCw6

Petro123fkthat,
Мы не про РЕСТ же тут.
А про аналогии. Про URI, контракты.
Это шире чем рест.
...
https://www.sql.ru/имя_приложения/показать?id=123
Не видно аналогию URI с API ака методами и параметрами?
Согласен что ошибка в синтаксисе выйдет в ошибку так же как и при вызове dll?
Да, я тут натянул сову на глобус, но аналогии всегда натяжка.
Имхо.

Ну, скуль, как бы и не заявляет, что он РЕСТ АПИ. Хотя, строго говоря, нет такого как "REST - не REST". Формально, все что использует HTTP это REST. Есть, просто некая модель "REST maturity level", где градации (по-моему от 1 до 5) по тому, насколько АПИ системы использует возможности HTTP. SOAP, например, там низший, из касты неприкасаемых Там тупой POST на один урл, вся инфа в боди запроса в ХМЛ. Но, дальше уже начинается подъем из днища