Дизайн интерфейса / Дизайн API: Общий метод против определенных методов

Question

В настоящее время мы думаем о том, как разработать интерфейс для других систем.

Мой коллега хотел бы реализовать универсальный интерфейс (например, doIt (JSONArray)), где вы помещаете нужную информацию, которую хотели бы сделать, в JSONObject, чтобы вызовы, например, выглядеть так: doIt('{"method":"getInformation", "id":"1234", "detailLevel": "2"}') doIt('{"method":"getEmployeeInfo", "EmployeeId":"4567", "company": "Acme Inc."}')

(я использовал «и» в этом примере только для демонстрационных целей. Я знаю, что мне пришлось избежать «в реальной системе»). Этот метод затем будет доступен через http, так что я хотел бы http://mysite/doIt?parm={JSONObject}

Мой подход заключается в использовании различных интерфейсов с соответствующими параметрами, чтобы у меня был интерфейс getInformation(1234,2) и getEmployeeInfo(4567,"Acme Inc."). Так что для доступа через http моя схема будет выглядеть так: http://mysite/getInformation?id=1234&detailLevel=2 и http://mysite/getEmployeeInfo?employeeId=4567&company=acmeinc.

Для клиентов, обращающихся к нашему сервису, мы хотим предоставить специальные библиотеки, которые инкапсулируют поведение. Например. будет клиент java-lib, который переводит вызов клиента getEmployeeInfo (..) либо в

http://mysite/doIt?parm={'{"method":"getEmployeeInfo", "EmployeeId":"4567", "company": "Acme Inc."}'}

или

http://mysite/getEmployeeInfo?employeeId=4567&company=acmeinc.

и затем вернуть результат.

Так что для клиентов будет полностью прозрачно, как работает бэкэнд, если они используют библиотеку, которая обрабатывает «перевод».

Как вы думаете, каковы плюсы и минусы каждой идеи? Мне больше нравится мой подход, потому что он выглядит «чище». Но с этим чувством трудно спорить. Возможно, вы можете дать мне (или ему) некоторые мысли о дизайне, а также коснуться областей (масштабируемость, безопасность, ...) или предоставить полезные ссылки по этому вопросу

Answer 1

Я бы, наверное, проголосовал за решение JSON, даже если они более или менее эквивалентны. (Оба легко расширяемые, стандартные, перспективные решения.)

Причины выбора JSON:

• Существует множество различных библиотек для разных платформ, которые помогают создавать правильные объекты, проверять правильность строковых данных и т. Д.

• Демонстрация JSON-данных в объекты. Некоторые библиотеки (например, Gson ) могут автоматически маршалировать и демаршировать JSON в объекты. Спасает вас от написания собственного кода, и вы получаете преимущество от использования кода, который был протестирован другими.

• Поддержка новых интерфейсов. Предположим, что вы изменили свой метод транспорта на сокеты, ftp (!) Или что-то еще. Вы по-прежнему можете отправлять объекты JSON на сервер, используя другой транспорт.

Answer 2

Решение JSON может быть лучше, потому что вы можете отправить сложный объект проще

Но здесь есть лишь небольшая детализация синтаксиса, пусть босс выберет (или сделает голосование) и создаст ваше программное обеспечение.