Решения для веб-сервисов от Mac

Question

Попытка найти способ быстрой разработки веб-сервисов на платформе Mac Server, которые будут обслуживаться через Apache и должны иметь возможность записи в простые файлы или SQL Lite на Mac.

У нас есть навыки .net, ObjC, C ++, Python и Java. Мы уже много работали над веб-сервисами в Windows и, возможно, перейдем на Azure, когда будем разрабатывать продукт.

Наш сервер разработки находится на Mac OSX 10.5.8, и у нас ограниченный бюджет времени и средств для создания прототипа для небольшой бета-группы (<500 транзакций в день), который мы позже сможем переработать. </p>

Мы думаем, что мыло, возможно, ОТДЫХ. Не уверены, что доступно для Mac?

Любая помощь приветствуется //:)

Answer 1

Если вы разрабатываете услугу, вы должны иметь представление о том, каких клиентов вы пытаетесь обслуживать. Если эти клиенты ожидают общения с сервисом SOAP, вам понадобится SOAP. Если вы просто используете JavaScript-код в браузере, вероятно, достаточно REST.

Apache CXF , являющийся 100% открытым исходным кодом Java, может использоваться для создания служб REST или SOAP на MacOS или в любом другом месте. Есть, конечно, и другие варианты.

Answer 2

А как насчет Ruby on Rails? Простота развертывания, отлично работает на Mac - и тривиально настроить веб-сервисы RESTful для.

Если вам не нужна вся магия Rails, другой (хотя и) вариант Ruby будет использовать Sinatra - я бы попросил любого найти библиотеку веб-сервисов RESTful, которую проще использовать, чем это - это так элегантно и так просто. Я, прежде всего, разработчик .Net, но в одно мгновение подобрал Руби и Синатру.

В любом случае, я бы держался подальше от SOAP - по-моему, в наши дни он слишком негибкий. В мире живых интернет-API Web 2.0 создание веб-сервисов RESTful - это более простой, быстрый (и меньший) вариант. Мы использовали SOAP исключительно там, где я работаю, но реальность такова, что он просто не доставляет так же, как REST. Благодаря доступности JSON и XML-сред для сериализации для любого языка, даже передача объектов становится тривиальной. SOAP сложнее масштабировать, сложнее тестировать, использует большую пропускную способность и не так гибок. Не все могут говорить SOAP (из коробки), но скажите мне что-то, что не может сделать HTTP-запрос?