#web-services #json #api #interface
#веб-сервисы #json #API #интерфейс
Вопрос:
в настоящее время мы думаем о том, как разработать интерфейс для других систем.
Мой коллега хотел бы реализовать универсальный интерфейс (например, для 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=1234amp;detailLevel=2 и http://mysite/getEmployeeInfo?employeeId=4567amp;company=acmeinc.
Для клиентов, обращающихся к нашему сервису, мы хотим предоставить специальные библиотеки, которые инкапсулируют bevahiour. Например. будет клиентская java-библиотека, которая преобразует клиентский вызов getEmployeeInfo (..) либо в
http://mysite/doIt?parm={'{"method":"getEmployeeInfo", "EmployeeId":"4567", "company": "Acme Inc."}'}
или для
http://mysite/getEmployeeInfo?employeeId=4567amp;company=acmeinc.
а затем верните результат.
Таким образом, для клиентов будет полностью прозрачно, как работает серверная часть, если они используют библиотеку, которая обрабатывает «перевод».
Как вы думаете, каковы плюсы и минусы каждой идеи? Мне больше нравится мой подход, потому что он выглядит «чище». Но это всего лишь ощущение, с которым трудно спорить. Возможно, вы могли бы высказать мне (или ему) несколько мыслей о дизайне, а также затронуть области (масштабируемость, безопасность, …) или предоставить полезные ссылки по этому вопросу
Ответ №1:
Я бы, вероятно, проголосовал за решение в формате JSON, даже если они более или менее эквивалентны. (Оба легко расширяемые, стандартные, перспективные решения.)
Причины выбора JSON:
-
Существует множество различных библиотек для разных платформ, которые помогают вам создавать правильные объекты, проверять, что строковые данные допустимы, и т.д.
-
Разделение данных JSON на объекты. Некоторые библиотеки (например, Gson) могут автоматически маршалировать и разархивировать JSON в объекты. Избавляет вас от написания собственного кода, и вы получаете преимущество от использования кода, который был протестирован другими.
-
Поддержка новых интерфейсов. Предположим, что вы меняете свой транспортный метод на сокеты, ftp (!) или что-то еще. Вы все еще можете отправлять объекты JSON на свой серверный сервер, используя другой транспорт.
Комментарии:
1. Хорошо, но что, если API следует использовать с другого клиента (например, веб-браузера javascript). Вам не кажется, что сначала создать JSON-объект, а затем отправить его на сервер «сложнее»? В другом случае вам просто нужно ввести значения в URL / post-запросе (это не такая уж большая разница .. я знаю.)
2. Или у вас действительно не может быть RESTful access с этой версией (моя тоже не RESTful, но вы могли бы представить что-то вроде mycomp / employee / 2345 / acmeinc ), но я действительно не вижу здесь преимущества…
3. JSON — это сокращение от обозначения объектов JavaScript, поэтому у вас определенно не возникло бы проблем с веб-браузером javascript 😉 И нет, создать объект JSON не сложно.
Ответ №2:
Я понимаю, что этот вопрос устарел, но я думаю, что ответы здесь направят разработчиков по неверному пути.
По моему опыту, вы всегда должны склоняться к более конкретным методам. Универсальные методы сложно тестировать, их сложно обдумать и они не обеспечивают (или минимальную) поддержку IDE / компилятора. Такой API, который вы описываете, ничего не сообщает пользователю о том, что он будет делать.
Ваш собственный дизайн api намного лучше.
При этом необходимо соблюдать баланс.
Ответ №3:
Решение в формате JSON могло бы быть лучше, потому что вы можете проще отправлять сложный объект
Но здесь это всего лишь небольшая синтаксическая деталь, позвольте боссу выбирать (или голосовать) и создавать ваше программное обеспечение.
Комментарии:
1. Боссу все равно, пока это работает и надежно в будущем 😉