Конечные точки REST / SOAP для службы WCF

Чтобы добавить к другим ответам, реализовав java.io.Serializable, вы получаете возможность «автоматической» сериализации для объектов вашего класса. Нет необходимости реализовывать какую-либо другую логику, она будет работать. Java-среда выполнения использует рефлексию для определения того, как маршалировать и де-маршалировать ваши объекты.

В более ранней версии Java отражение было очень медленным, и поэтому сериализация крупных графиков объектов (например, в клиент-серверных приложениях RMI) было немного проблем с производительностью. Чтобы справиться с этой ситуацией, был предоставлен интерфейс java.io.Externalizable, который похож на java.io.Serializable, но с настраиваемыми механизмами для выполнения функций маршаллинга и развязывания (вам нужно реализовать методы readExternal и writeExternal в вашем классе). Это дает вам возможность обойти узкое место производительности отражения.

В последних версиях Java (начиная с версии 1.3, конечно) производительность отражения намного лучше, чем раньше, и поэтому это гораздо менее проблематично. Я подозреваю, что вам будет трудно получить значимую выгоду от Externalizable с современной JVM.

Кроме того, встроенный механизм сериализации Java не является единственным, вы можете получить сторонние замены, такие как JBoss Serialization, что значительно быстрее и является заменой для замены default.

Большой недостаток Externalizable заключается в том, что вы должны сами поддерживать эту логику - если вы добавляете, удаляете или изменяете поле в своем классе, вы должны изменить свой writeExternal / readExternal методы для его учета.

Таким образом, Externalizable является реликвией Java 1.1 дней. В этом нет необходимости.

417
задан John Saunders 4 January 2011 в 02:28
поделиться

3 ответа

Можно представить сервис в двух различных конечных точках. SOAP можно использовать привязку, которые поддерживают SOAP, например, basicHttpBinding, УСПОКОИТЕЛЬНЫЙ, может использовать webHttpBinding. Я предполагаю, что Ваш сервис REST будет в JSON, в этом случае, необходимо настроить эти две конечных точки со следующей конфигурацией поведения

<endpointBehaviors>
  <behavior name="jsonBehavior">
    <enableWebScript/>
  </behavior>
</endpointBehaviors>

, пример конфигурации конечной точки в сценарии

<services>
  <service name="TestService">
    <endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
    <endpoint address="json" binding="webHttpBinding"  behaviorConfiguration="jsonBehavior" contract="ITestService"/>
  </service>
</services>

так, сервис будет доступен по телефону

Применяется [WebGet] к контракту на операцию для создания его УСПОКОИТЕЛЬНЫМ. например,

public interface ITestService
{
   [OperationContract]
   [WebGet]
   string HelloWorld(string text)
}

Примечание, если остальное сервис не находится в JSON, параметрах операций, не может содержать составной тип.

Ответ на сообщение для SOAP и УСПОКОИТЕЛЬНОГО POX (XML)

Для простого XML как формат возврата, это - пример, который работал бы и на SOAP и на XML.

[ServiceContract(Namespace = "http://test")]
public interface ITestService
{
    [OperationContract]
    [WebGet(UriTemplate = "accounts/{id}")]
    Account[] GetAccount(string id);
}

поведение POX для REST Простые конечные точки XML

<behavior name="poxBehavior">
  <webHttp/>
</behavior>

<services>
  <service name="TestService">
    <endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
    <endpoint address="xml" binding="webHttpBinding"  behaviorConfiguration="poxBehavior" contract="ITestService"/>
  </service>
</services>

Сервис будет доступен в [1 127]

запрос REST попытка это в браузере,

http://www.example.com/xml/accounts/A123

запрос SOAP клиентская конфигурация конечной точки для сервиса SOAP после добавления сервисной ссылки,

  <client>
    <endpoint address="http://www.example.com/soap" binding="basicHttpBinding"
      contract="ITestService" name="BasicHttpBinding_ITestService" />
  </client>

в C#

TestServiceClient client = new TestServiceClient();
client.GetAccount("A123");

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

578
ответ дан 4 revs, 3 users 98% 4 January 2011 в 02:28
поделиться

На этот пост уже есть очень хороший ответ в "Community wiki", и я также рекомендую заглянуть в Rick Strahl's Web Blog, там есть много хороших постов о WCF Rest, например этот.

Я использовал оба, чтобы получить такой вид MyService-сервиса... Затем я могу использовать REST-интерфейс из jQuery или SOAP из Java.

Это из моего Web.Config:

<system.serviceModel>
 <services>
  <service name="MyService" behaviorConfiguration="MyServiceBehavior">
   <endpoint name="rest" address="" binding="webHttpBinding" contract="MyService" behaviorConfiguration="restBehavior"/>
   <endpoint name="mex" address="mex" binding="mexHttpBinding" contract="MyService"/>
   <endpoint name="soap" address="soap" binding="basicHttpBinding" contract="MyService"/>
  </service>
 </services>
 <behaviors>
  <serviceBehaviors>
   <behavior name="MyServiceBehavior">
    <serviceMetadata httpGetEnabled="true"/>
    <serviceDebug includeExceptionDetailInFaults="true" />
   </behavior>
  </serviceBehaviors>
  <endpointBehaviors>
   <behavior name="restBehavior">
    <webHttp/>
   </behavior>
  </endpointBehaviors>
 </behaviors>
</system.serviceModel>

А это мой сервис-класс (.svc-codebehind, интерфейсы не требуются):

    /// <summary> MyService documentation here ;) </summary>
[ServiceContract(Name = "MyService", Namespace = "http://myservice/", SessionMode = SessionMode.NotAllowed)]
//[ServiceKnownType(typeof (IList<MyDataContractTypes>))]
[ServiceBehavior(Name = "MyService", Namespace = "http://myservice/")]
public class MyService
{
    [OperationContract(Name = "MyResource1")]
    [WebGet(ResponseFormat = WebMessageFormat.Xml, UriTemplate = "MyXmlResource/{key}")]
    public string MyResource1(string key)
    {
        return "Test: " + key;
    }

    [OperationContract(Name = "MyResource2")]
    [WebGet(ResponseFormat = WebMessageFormat.Json, UriTemplate = "MyJsonResource/{key}")]
    public string MyResource2(string key)
    {
        return "Test: " + key;
    }
}

На самом деле я использую только Json или Xml, но эти оба здесь для демонстрации. Это GET-запросы для получения данных. Для вставки данных я бы использовал метод с атрибутами:

[OperationContract(Name = "MyResourceSave")]
[WebInvoke(Method = "POST", ResponseFormat = WebMessageFormat.Json, UriTemplate = "MyJsonResource")]
public string MyResourceSave(string thing){
    //...
38
ответ дан 22 November 2019 в 23:24
поделиться

Если вы хотите разработать только одну веб-службу и размещать его на многих разных конечных точках (например, SOAP + REST, с выводами XML, JSON, CSV, HTML). Вам также следует подумать об использовании ServiceStack , который я построил именно для этой цели, где каждый сервис, который вы разрабатываете, автоматически доступен на конечных точках SOAP и REST прямо из коробки без какой-либо конфигурации.

В примере Hello World показано, как создать простую службу с помощью всего (конфигурация не требуется):

public class Hello {
    public string Name { get; set; }
}

public class HelloResponse {
    public string Result { get; set; }
}

public class HelloService : IService
{
    public object Any(Hello request)
    {
        return new HelloResponse { Result = "Hello, " + request.Name };
    }
}

Никакой другой конфигурации не требуется, и эта служба сразу доступна с REST в:

Он также имеет встроенный удобный HTML-вывод (при вызове с HTTP-клиентом, имеющим Accept: text / html , например, браузер), чтобы вы могли лучше визуализировать результаты своих услуг.

Обработка различных команд REST также тривиальна, вот полное приложение CRUD службы REST на 1 странице C # (меньше, чем потребуется для настройки WCF;):

25
ответ дан 22 November 2019 в 23:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: