REST, потому что стильно, модно, молодёжно!

А если серьёзно, то раз приложение небольшое, то бояться переизбытка сущностей явно не стоит. Зато всё будет чётко и стройно.

Или у тебя много не-CRUD методов намечается?

Или у тебя много не-CRUD методов намечается?

Пока даже не знаю, но на ум не приходят нерешаемые не-CRUD юзкейсы :)

Меня больше перспектива беспокоит - с развитием приложения количество сущностей будет расти в любом случае.

С развитием приложения расти будет всё без исключения. Количество сущностей — последнее, о чём следует беспокоиться, имхо.

4 метода для кажой

Вообще-то 7 ;) : index, show, create, update, destroy, new, edit.

Что вы подразумеваете под этими терминами?

Что вы подразумеваете под этими терминами?

Возможно я ошибаюсь, но:

• RPC - Remote Procedure Call вызов API метода по URL, например: https://example.com/entity/create?param1=value1 от HTTP метода не зависит
  
• REST - REpresentational State Transfer вызов нескольких API методов происходит по одному и тому же URL, например: https://example.com/entity , но если метод HTTP GET, то вытягиваем информацию о сущностях, POST - добавить новую сущность итд.

Вообще-то 7 ;) : index, show, create, update, destroy, new, edit.

Да это же всё кардинельно меняет :)

Честно говоря, подумал что у тебя там RPC это какой-нибудь SOAP.

А так, какая разница, смешивай их, наслаждайся жизнью

То что вы называете RPC - это часть конвенции REST, называется query parameters. Они используются для конфигурирования способа доступа к ресурсу, сущности. Тоесть сущность как бы одна, и даже форма представления одна, но некоторая конфигурация требуется

http://myservice.com/my-resource/entity1?lang=en

То, что она JSON - нужно указать в Accept, но всякие особые параметры типо lang, могут быть в query params. Не обязательно это лучшее решение именно для локализации, но я думаю суть вы уловили. Дело в том что пусть даже lang и будет подресурсом, /my-resource/entity1/en, но почему выделили именно язык? А если я хочу еще минифицированную версию? И именно минифицированную на японском языке? С query params я так и сделаю, /entity1?lang=jp&mini=true

И да, достаточно там методов :) Учитывая что POST означает general purpose operation

Тогда что такое RPC? Каково отличие?

Я потому и спросил, нет никакого RPC, по крайней мере мне неизвестно чтобы это так называли, использование query params. RPC - это общее название схемы синхронного запроса ответа, наверное...

RPC

Да пофиг, если там все взаимодействие будет по plain http. У нас в проекте сейчас «типа rest», но используется только get для получения данных и post на под-урлы для всех модифицирующих запросов. Т.е. например GET /users?id=123 вернет пользователя с таким айдишником, POST /users/delete и id=123&cascade=true в url encoded форме убьет пользователя и все его данные.

нет никакого RPC, по крайней мере мне неизвестно чтобы это так называли, использование query params.

Нет, входные параметры тоже сериализуются в JSON и передаются через POST или GET (query params) data (подобно GitHub API).

От того что ты будешь дергать кастомый урл, он RPC не становится.