Replicate REST API с SOAP

Question

У меня есть простой REST API, который отправляет данные в формате JSON, такие как это:

http://myapp/color (POST w/ data in JSON) - Creates a new color in DB 
http://myapp/color/id (GET) - Fetches details for a color from DB 
http://myapp/color (GET) - Fetches details for all colors in DB 

Я хотел бы создать SOAP API для этих трех функций. Поэтому я собираюсь с Spring-WS.

Я создал API SOAP для создания. Со следующим XSD

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:hr="http://www.myveryimportantcompany.com/tr/schemas" 
      targetNamespace="http://www.myveryimportantcompany.com/tr/schemas" 
      elementFormDefault="qualified" 
      attributeFormDefault="unqualified"> 
<xs:element name="ColorRequest"> 
    <xs:complexType> 
     <xs:all> 
      <xs:element name="Color" type="hr:ColorType"/> 
     </xs:all> 
    </xs:complexType> 
</xs:element> 
<xs:complexType name="ColorType"> 
    <xs:sequence> 
     <xs:element name="name" type="xs:string"/> 
    </xs:sequence> 
</xs:complexType> 
<xs:element name="ColorResponse"> 
    <xs:complexType> 
     <xs:sequence> 
      <xs:element name="status" type="xs:string"/> 
     </xs:sequence> 
    </xs:complexType> 
</xs:element> 
</xs:schema> 

Я также написал функциональный тест для выше которого работает отлично.

Вопросы - Я никогда не создавал SOAP WS в прошлом, поэтому, пожалуйста, игнорируйте, если вопросы глупы.

• Как выглядит XSD для оставшихся двух функций?
• Нужен ли мне отдельный XSD для каждой функции?
• Могу ли я проверить службу SOAP с помощью графического интерфейса? Я дал SOAP GUI шоу, но ему нужен WSDL. Как я могу это создать?

PS: Я использую плагин Spring-WS от grails.

Answer 1

Это своего рода субъективный вопрос. Я постараюсь ответить как можно больше, чтобы сделать его полезным. Потерпите меня. :)

Первой вещь Первый: -

• SpringWS плагин использует контрактный первый веб-сервис. Схема, которую вы создали здесь, должна заключаться в контракте на базовый веб-сервис.
• У каждого из вебсервисов должен быть свой собственный контракт, который означает его собственную схему.
• SpringWS следует за соглашением о создании Endpoint с именем, аналогичным названию договора schema.
• Вы можете использовать наследование в конечных точках, которые помогут вам создать единую схему xsd для всех контрактов. В этом случае вы должны наследовать родительскую конечную точку в соответствующих дочерних конечных точках.

Пример: -
Для удобства каждого позволяет использовать User службу вместо Color.

//Domain:- 
class User{ 
    String name 
    String email 
    Integer age 
} 

Я хотел бы подготовить базовую схему для этого объекта, некоторые, что похоже на то, что вы делали раньше для Color:

<!-- User.xsd --> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:hr="http://www.myveryimportantcompany.com/tr/schemas" 
      targetNamespace="http://www.myveryimportantcompany.com/tr/schemas" 
      elementFormDefault="qualified" 
      attributeFormDefault="unqualified"> 
<xs:complexType name="UserType"> 
    <xs:sequence> 
     <xs:element name="name" type="xs:string"/> 
     <xs:element name="email" type="xs:string"/> 
     <xs:element name="age" type="xs:integer"/> 
    </xs:sequence> 
</xs:complexType> 

<xs:element name="User" type="hr:UserType"/> 

</xs:schema> 

Теперь приходят к каждому контракту для каждой службы: -

<!-- GetUserService.xsd --> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
      xmlns:hr="http://www.myveryimportantcompany.com/tr/schemas" 
      targetNamespace="http://www.myveryimportantcompany.com/tr/schemas" 
      elementFormDefault="qualified" 
      attributeFormDefault="unqualified"> 
<xs:element name="GetUserRequest" type="hr:GetUserRequestType"/> 
<xs:complexType name="GetUserRequestType"> 
    <xs:sequence> 
     <xs:element name="name" type="xs:string"/> 
    </xs:sequence> 
</xs:complexType> 

<xs:element name="GetUserResponse" type="hr:GetUserResponseType"/>  
<xs:complexType name="GetUserRequestType"> 
    <xs:sequence> 
     <xs:element ref="hr:User"/> 
    </xs:sequence> 
</xs:complexType> 
</xs:schema> 

Аналогичным образом вы можете получить UpdateUserService.xsd, выполнив обновление [POST, PUT].

В качестве альтернативы, вы можете накапливать все xsds к одному контракту по имени UserServices.xsd

РИСКОВАННАЯ
В случае, если у вас есть только один XSD для всех услуги, то вы должны создать родительский конечную точку с именем (точно так же) в UserServicesEndpoint.groovy (см springws документы, как создать конечные точки), то ваши услуги конечная точка будет вероятно

class GetUserServiceEndpoint extends UserServicesEndpoint{....}
class UpdateUserServiceEndpoint extends UserServicesEndpoint{....}

Если у вас есть все xsds отдельно, вам не нужно наследование.

Ответы на вопросы:

1. Как бы XSD выглядеть как для остальных двух функций?
   К настоящему времени вы знаете, как это должно выглядеть. Имена должны быть что-то вроде UpdateColorService.xsd, GetColorService.xsd, GetAllColorsService.xsd

2. ли нужен отдельный XSD для каждой функции?
   Следуйте выше. Вы можете иметь отдельный или вы можете иметь их в одном родителе xsd. В этом случае также должна быть родительская конечная точка.

3. Могу ли я проверить сервис SOAP с помощью графического интерфейса? Я дал SOAP GUI шоу, но ему нужен WSDL. Как я могу это создать?
   Да, вы можете. Лучший инструмент, который я нашел, - SoapUI (для меня достаточно бесплатной версии). Вы также можете использовать Apache JMeter, если вам это удобно. Контракт-первые услуги всегда нужен WSDL для запуска. Как часть плагина SpringWS, у вас есть великолепная поддержка DSL, которая создает WSDL для вас после запуска приложения. Следуйте за документами еще раз. Я могу объяснить это в другом вопросе, потому что этот ответ стал эпопеей.

Слова Совета:

• Наконец, почему вам нужен SOAP Service, когда весь мир покоится в мире? :)

• плагин springws почти устарел и не поддерживается в течение многих лет. Я настроил плагин на свои нужды и еще не отправил его в Grails PLugins. Не хотелось? Но я думаю, что я должен это сделать, поскольку @Anthony использует его. :)

• У плагина есть банки внутри каталога проекта lib, который может столкнуться с вашими зависимостями.

• Плагин использует старую версию spring-ws-core, которая, безусловно, будет врезаться с spring-core:3.1.2, который поставляется с Grails 2.2.x.

• Вы можете получить ошибки компиляции с более новой версией JDK (7 или выше).