Реализация публичного API в Java. Какие рамки?

Question

В настоящее время я работаю над реализацией общедоступного API нашего веб-приложения. Приложение написано на Java.

Это финансовое приложение, развернутое на Tomcat. Мои пользователи могут управлять своими продажами, клиентами, покупками, запасами и т. Д. Это довольно большое приложение. Конец шрифта написан на Java / GWT. Бэкэнд хорошо написан на Java. Мы используем механизм GWT-RPC между.

Мы хотим предоставить способ доступа к финансовым данным (чтение + запись) через общедоступный API. Таким образом, разработчики смогут лучше интегрировать свое приложение (например, приложение для расчета заработной платы).

Мы не используем какие-либо рамки. Нет весны, Грааля, что угодно. Кроме того, нет Hibernate, JPA и т. Д. Это довольно старое приложение, с большим количеством проприетарного кода для ORM, XML-> javabean. проверка подлинности и т. д. Невозможно изменить все это, поскольку приложение уже работает, и оно просто работает таким образом.

Инфраструктура API будет находиться в другом поддомене и на другом сервере.

API должен использовать Oauth для аутентификации пользователей.

Я посмотрел на Grails, Play! Framework и Restlet, чтобы достичь своих целей

У кого-нибудь есть мысли о них? Я поступаю неправильно с этими структурами? Есть ли еще рамки, на которые стоит посмотреть?

Спасибо всем

Answer 1

Я бы порекомендовал последовать примеру Amazon и тому подобному и выставить этот API в качестве веб-сервисов, не обращая внимания на пользовательский интерфейс. У вас есть дальнейший выбор о SOAP против REST. Я думаю, вы обнаружите, что REST будет проще для ваших клиентов, потому что им нужно знать только HTTP.

Это не обязывает использовать какие-либо рамки, если вы не хотите. Серверная часть будет работать независимо от того, используете ли вы Spring, Hibernate, Grails и т. Д.

Вам бы пришлось переделать приложение, которое вы должны вызывать в сервисах, если вы хотите истинного повторного использования, но в долгосрочной перспективе это может стоить. Таким образом, и ваш пользовательский интерфейс, и клиенты будут использовать общий внутренний API.

Answer 2

Какие среды развертывания вы ожидаете использовать этот API.Это может сузить кругозор, стандартный ответ, если вы абсолютно не представляете, кто ваш клиент, по-прежнему предположительно SOAP (поскольку многие люди знают и принимают модное слово).

Answer 3

Если вы собираетесь предоставлять доступ для чтения / записи к приложению финансовых служб на основе Java через общедоступный Интернет, я бы посмотрел на веб-службы на основе SOAP с JAX-WS , поскольку есть довольнозрелые спецификации безопасности в WSS и API относительно просты в использовании и могут не требовать значительных изменений в существующем приложении.

REST в целом воспринимается как более легкий, но для этоготип приложения, который вы можете найти, ваша целевая аудитория в любом случае лучше знакома с SOAP.Все зависит от того, кто является вашей целевой аудиторией и чего именно вы пытаетесь достичь, но стоит подумать.

Answer 4

У меня есть мысли да.Финансовые приложения, как правило, не используют OAuth.Чтобы было ясно: никто с уязвимыми данными не использует OAuth.Это включает в себя конфиденциальность, медицинские и финансовые данные.