Да, это будет работать. Тем не менее, вы строите свой проект распределенной системы исходя из предположения, что модель данных очень проста и останется такой. Если создаваемое вами приложение успешно, вы можете быть уверены, что будут добавлены новые требования и будут запрошены новые функции.
Предоставление слоя данных, как вы предлагаете, тесно связывает ваши клиентские приложения с моделью данных, а использование http делает выполнение транзакций с несколькими запросами очень трудным. Я знаю, что вы сказали, что вам не нужно делать транзакции с несколькими запросами. Не сегодня, а может в следующем году?
Какова продолжительность жизни этого приложения? Если вы скажете больше, чем пару лет, я бы переосмыслил идею предоставления слоя данных удаленным клиентам. Одна из основных целей REST - разъединить клиентское и серверное приложения, чтобы позволить приложениям развиваться в течение длительного периода времени. Если у вас есть несколько клиентских приложений, обращающихся к распределенной службе, если она не разработана правильно, она может быстро столкнуться с неприятными проблемами обслуживания и управления версиями.
Изменить, чтобы ответить на вопрос в комментариях о клиенте, который должен понимать модель:
У вас есть два разных направления, которые вы можете использовать в отношении того, как клиент может взаимодействовать с представлением, полученным с сервера.
- Вы можете разрешить клиенту явно знать содержимое данных, содержащихся в представлении. То есть Клиент знает, что в некоторых элементах XML есть имя пользователя и пароль. Однако, если вы сделаете это, вы должны вернуть определенный тип носителя, например, Приложение / vnd.mycompany.user + XML. Вы не должны использовать application / xml, так как это ничего не говорит клиенту о том, что находится в XML-документе. Если клиент должен был знать, что «когда вы переходите на URL X», вы получаете «документ XML, содержащий элементы UserName и Password внутри элемента User», то вы нарушили самоописательное ограничение REST. В результате вы подключили конечную точку к типу носителя и фактически подключили клиента к этой конечной точке. Цель "гипермедиа ограничения" REST состоит в том, чтобы предотвратить связь между клиентом и конечными точками.
- Альтернативой является использование более общего типа мультимедиа, который просто предназначен для предоставления клиенту контента для отображения пользователю и предоставления пользователю опций, позволяющих клиенту предпринимать действия. Html media type позволяет вам сделать это, предоставив язык разметки, который можно использовать для возврата имени пользователя и пароля в двух тегах div. Используя тег html FORM и тег A, клиент может выполнять дополнительные операции с этим ресурсом. Выяснить, как сделать доступными все возможные операции, которые может иметь «пользовательский» объект, действительно RESTful-способом, сложно и требует совсем немного опыта, но конечный результат - это очень хорошо отделенные клиент и сервер. Посмотрите на веб-браузер в качестве примера, как часто вам нужно обновлять браузер, потому что веб-сайт изменил свое содержимое.
Проблема со вторым вариантом заключается в том, что при использовании только HTML взаимодействие с конечным пользователем имеет тенденцию быть довольно ограниченным, и именно здесь вступает Javascript. Одним из «необязательных» ограничений REST является использование загрузки кода. Javascript - это код, который загружается с сервера для обеспечения дополнительного поведения на клиенте. К сожалению, на мой взгляд, он также предоставляет людям возможность создавать веб-интерфейсы RESTful, которые возвращают application / xml, а затем используют javascript для интерпретации этого общего формата. Это решение отлично работает для первоначального разработчика веб-сайта, который использует RESTful API, потому что если изменяется содержимое XML-файла, тогда javascript может быть изменен и повторно загружен в браузер, и все хорошо. Однако для любого другого стороннего разработчика, который обращается к этому API, который не контролирует модель содержимого application / xml, их код становится полностью хрупким и потенциально может сломаться при изменении содержимого API. Спросите любого, кто написал какой-либо клиент для Твиттера, сколько раз их приложение ломалось из-за того, что Твиттер изменял содержание.
Используя первую опцию и назначая контенту определенный тип мультимедиа, разработчик сервера может представить новый тип мультимедиа под названием application / vnd.mycompany.userV2 + xml, и с помощью согласования контента существующие клиенты могут по-прежнему получать исходный мультимедиа тип и новые клиенты могут быть созданы для использования нового типа носителя. URL остается прежним, закладки не нарушаются, поскольку конечная точка и медиатип не связаны.
Если вы видите документацию API, в которой содержится список URL-адресов и содержимое, возвращаемое из этих URL-адресов, скорее всего, эти разработчики просто не получат REST и не получат преимуществ, которые предоставляет интерфейс RESTful. По иронии судьбы, пострадают не те разработчики, а сторонние разработчики, пытающиеся взаимодействовать с API!