Verhindern, dass Eigenschaften in der Web-API serialisiert werden

Ich verwende eine MVC 4-Web-API und asp.net-Webformulare 4.0, um eine Rest-API zu erstellen. Es funktioniert großartig:

[HttpGet]
public HttpResponseMessage Me(string hash)
{
    HttpResponseMessage httpResponseMessage;
    List<Something> somethings = ...

    httpResponseMessage = Request.CreateResponse(HttpStatusCode.OK, 
                                 new { result = true, somethings = somethings });

    return httpResponseMessage;
}

Jetzt muss ich verhindern, dass einige Eigenschaften serialisiert werden. Ich weiß, dass ich etwas LINQ über die Liste verwenden und nur die Eigenschaften abrufen kann, die ich benötige. Im Allgemeinen ist dies ein guter Ansatz, aber im vorliegenden Szenario ist das somethingObjekt zu komplex und ich benötige unterschiedliche Eigenschaften in unterschiedlichen Methoden Zur Laufzeit ist es einfacher, jede zu ignorierende Eigenschaft zu markieren.

Gibt es eine Möglichkeit, das zu tun?

Die ASP.NET-Web-API wird Json.Netals Standardformatierer verwendet. Wenn Ihre Anwendung also nur JSON als Datenformat verwendet, können Sie [JsonIgnore]die Eigenschaft für die Serialisierung ignorieren:

public class Foo
{
    public int Id { get; set; }
    public string Name { get; set; }

    [JsonIgnore]
    public List<Something> Somethings { get; set; }
}

Auf diese Weise wird das XML-Format jedoch nicht unterstützt. Wenn Ihre Anwendung das XML-Format mehr (oder nur XML) unterstützen muss, anstatt es zu verwenden Json.Net, sollten Sie das verwenden, [DataContract]das sowohl JSON als auch XML unterstützt:

[DataContract]
public class Foo
{
    [DataMember]
    public int Id { get; set; }
    [DataMember]
    public string Name { get; set; }

    //Ignore by default
    public List<Something> Somethings { get; set; }
}

Zum besseren Verständnis können Sie den offiziellen Artikel lesen .

Gemäß der Dokumentationsseite der Web-API JSON- und XML-Serialisierung in der ASP.NET-Web-API , um die Serialisierung für eine Eigenschaft, die Sie entweder verwenden können, explizit zu verhindern[JsonIgnore] für den Json-Serializer oder [IgnoreDataMember]für den Standard-XML-Serializer verwenden können.

Beim Testen ist mir jedoch aufgefallen, dass [IgnoreDataMember]die Serialisierung sowohl für XML- als auch für Json-Anforderungen verhindert wird. Daher würde ich empfehlen, diese zu verwenden, anstatt eine Eigenschaft mit mehreren Attributen zu dekorieren.

Anstatt standardmäßig alles serialisieren zu lassen, können Sie den "Opt-In" -Ansatz verwenden. In diesem Szenario dürfen nur die von Ihnen angegebenen Eigenschaften serialisiert werden. Sie tun dies mit dem DataContractAttributeund DataMemberAttribute, das im System.Runtime.Serialization- Namespace zu finden ist.

Das DataContactAttributewird auf die Klasse angewendet, und das DataMemberAttributewird auf jedes Mitglied angewendet, das serialisiert werden soll:

[DataContract]
public class MyClass {

  [DataMember]
  public int Id { get; set;} // Serialized

  [DataMember]
  public string Name { get; set; } // Serialized

  public string DontExposeMe { get; set; } // Will not be serialized
}

Ich wage zu sagen, dass dies ein besserer Ansatz ist, weil er Sie dazu zwingt, explizite Entscheidungen darüber zu treffen, was durch Serialisierung erreicht werden soll oder nicht. Außerdem können Ihre Modellklassen selbstständig in einem Projekt leben, ohne von JSON.net abhängig zu sein, nur weil Sie sie an einem anderen Ort zufällig mit JSON.net serialisieren.

Dies hat bei mir funktioniert: Erstellen Sie einen benutzerdefinierten Vertragsauflöser mit einer öffentlichen Eigenschaft namens AllowList vom Typ string array. Ändern Sie in Ihrer Aktion diese Eigenschaft abhängig davon, was die Aktion zurückgeben muss.

1. Erstellen Sie einen benutzerdefinierten Vertragsauflöser:

public class PublicDomainJsonContractResolverOptIn : DefaultContractResolver
{
    public string[] AllowList { get; set; }

    protected override IList<JsonProperty> CreateProperties(Type type, MemberSerialization memberSerialization)
    {
        IList<JsonProperty> properties = base.CreateProperties(type, memberSerialization);

        properties = properties.Where(p => AllowList.Contains(p.PropertyName)).ToList();
        return properties;
    }
}

2. Verwenden Sie den benutzerdefinierten Vertragsauflöser in Aktion

[HttpGet]
public BinaryImage Single(int key)
{
    //limit properties that are sent on wire for this request specifically
    var contractResolver = Configuration.Formatters.JsonFormatter.SerializerSettings.ContractResolver as PublicDomainJsonContractResolverOptIn;
    if (contractResolver != null)
        contractResolver.AllowList = new string[] { "Id", "Bytes", "MimeType", "Width", "Height" };

    BinaryImage image = new BinaryImage { Id = 1 };
    //etc. etc.
    return image;
}

Dieser Ansatz ermöglichte es mir, bestimmte Anforderungen zuzulassen / nicht zuzulassen, anstatt die Klassendefinition zu ändern. Wenn Sie keine XML-Serialisierung benötigen, vergessen Sie nicht, diese in Ihrer zu App_Start\WebApiConfig.csdeaktivieren. Andernfalls gibt Ihre API blockierte Eigenschaften zurück, wenn der Client XML anstelle von JSON anfordert.

//remove xml serialization
var appXmlType = config.Formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");
config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);

Ich werde Ihnen zwei Möglichkeiten zeigen, um das zu erreichen, was Sie wollen:

Erster Weg: Dekorieren Sie Ihr Feld mit dem JsonProperty-Attribut, um die Serialisierung dieses Felds zu überspringen, wenn es null ist.

public class Foo
{
    public int Id { get; set; }
    public string Name { get; set; }

    [JsonProperty(NullValueHandling = NullValueHandling.Ignore)]
    public List<Something> Somethings { get; set; }
}

Zweiter Weg: Wenn Sie mit einigen komplexen Szenarien verhandeln, können Sie die Web-API-Konvention ("ShouldSerialize") verwenden, um die Serialisierung dieses Felds abhängig von einer bestimmten Logik zu überspringen.

public class Foo
{
    public int Id { get; set; }
    public string Name { get; set; }

    public List<Something> Somethings { get; set; }

    public bool ShouldSerializeSomethings() {
         var resultOfSomeLogic = false;
         return resultOfSomeLogic; 
    }
}

WebApi verwendet JSON.Net und verwendet Reflection für die Serialisierung. Wenn also beispielsweise die ShouldSerializeFieldX () -Methode erkannt wurde, wird das Feld mit dem Namen FieldX nicht serialisiert.

Ich bin zu spät zum Spiel, aber anonyme Objekte würden den Trick machen:

[HttpGet]
public HttpResponseMessage Me(string hash)
{
    HttpResponseMessage httpResponseMessage;
    List<Something> somethings = ...

    var returnObjects = somethings.Select(x => new {
        Id = x.Id,
        OtherField = x.OtherField
    });

    httpResponseMessage = Request.CreateResponse(HttpStatusCode.OK, 
                                 new { result = true, somethings = returnObjects });

    return httpResponseMessage;
}

Versuchen Sie es mit der IgnoreDataMemberEigenschaft

public class Foo
    {
        [IgnoreDataMember]
        public int Id { get; set; }
        public string Name { get; set; }
    }

Fast wie die Antwort von greatbear302, aber ich erstelle ContractResolver pro Anfrage.

1) Erstellen Sie einen benutzerdefinierten ContractResolver

public class MyJsonContractResolver : DefaultContractResolver
{
    public List<Tuple<string, string>> ExcludeProperties { get; set; }

    protected override JsonProperty CreateProperty(MemberInfo member, MemberSerialization memberSerialization)
    {
        JsonProperty property = base.CreateProperty(member, memberSerialization);

        if (ExcludeProperties?.FirstOrDefault(
            s => s.Item2 == member.Name && s.Item1 == member.DeclaringType.Name) != null)
        {
            property.ShouldSerialize = instance => { return false; };
        }

        return property;
    }
}

2) Verwenden Sie einen benutzerdefinierten Vertragsauflöser in Aktion

public async Task<IActionResult> Sites()
{
    var items = await db.Sites.GetManyAsync();

    return Json(items.ToList(), new JsonSerializerSettings
    {
        ContractResolver = new MyJsonContractResolver()
        {
            ExcludeProperties = new List<Tuple<string, string>>
            {
                Tuple.Create("Site", "Name"),
                Tuple.Create("<TypeName>", "<MemberName>"),
            }
        }
    });
}

Bearbeiten:

Es hat nicht wie erwartet funktioniert (Resolver pro Anfrage isolieren). Ich werde anonyme Objekte verwenden.

public async Task<IActionResult> Sites()
{
    var items = await db.Sites.GetManyAsync();

    return Json(items.Select(s => new
    {
        s.ID,
        s.DisplayName,
        s.Url,
        UrlAlias = s.Url,
        NestedItems = s.NestedItems.Select(ni => new
        {
            ni.Name,
            ni.OrdeIndex,
            ni.Enabled,
        }),
    }));
}

Möglicherweise können Sie AutoMapper verwenden, die .Ignore()Zuordnung verwenden und dann das zugeordnete Objekt senden

CreateMap<Foo, Foo>().ForMember(x => x.Bar, opt => opt.Ignore());

Funktioniert gut, indem Sie einfach Folgendes hinzufügen: [IgnoreDataMember]

Über dem richtigen Typ, wie:

public class UserSettingsModel
{
    public string UserName { get; set; }
    [IgnoreDataMember]
    public DateTime Created { get; set; }
}

Dies funktioniert mit ApiController. Der Code:

[Route("api/Context/UserSettings")]
    [HttpGet, HttpPost]
    public UserSettingsModel UserSettings()
    {
        return _contextService.GetUserSettings();
    }

Aus irgendeinem Grund [IgnoreDataMember]funktioniert das nicht immer bei mir und ich bekomme manchmal StackOverflowException(oder ähnliches). Also habe ich stattdessen (oder zusätzlich) angefangen, ein Muster zu verwenden, das ungefähr so ​​aussieht, wenn ich POSTin Objectsmeine API gehe:

[Route("api/myroute")]
[AcceptVerbs("POST")]
public IHttpActionResult PostMyObject(JObject myObject)
{
    MyObject myObjectConverted = myObject.ToObject<MyObject>();

    //Do some stuff with the object

    return Ok(myObjectConverted);
}

Im Grunde genommen übergebe ich ein JObjectund konvertiere es, nachdem es empfangen wurde, in Aviod-Probleme, die durch den eingebauten Serializer verursacht werden und manchmal eine Endlosschleife verursachen, während die Objekte analysiert werden.

Wenn jemand einen Grund kennt, warum dies in irgendeiner Weise eine schlechte Idee ist, lassen Sie es mich bitte wissen.

Es kann erwähnenswert sein, dass es der folgende Code für eine EntityFramework-Klasseneigenschaft ist, der das Problem verursacht (wenn zwei Klassen aufeinander verweisen):

[Serializable]
public partial class MyObject
{
   [IgnoreDataMember]
   public MyOtherObject MyOtherObject => MyOtherObject.GetById(MyOtherObjectId);
}

[Serializable]
public partial class MyOtherObject
{
   [IgnoreDataMember]
   public List<MyObject> MyObjects => MyObject.GetByMyOtherObjectId(Id);
}