Full object graph should be displayed for WebApi controller models about swashbuckle.odata HOT 14 CLOSED

If you do a straight OData GET against your entity set, the model returned looks like that JSON, yes? I'm trying to show the data model as it will be returned by default (when you don't use $expand). The full model can be viewed via the metadata link. Does that work?

from swashbuckle.odata.

Rich,
The problem is related to the swagger docs look below:

before:

after:

from swashbuckle.odata.

Sorry to bother you, any news about this bug? We have the extension installed on our production server and just want to know if the bug is solvable.

from swashbuckle.odata.

It is solvable with a code change. So thats not an ODATA API?

from swashbuckle.odata.

Exactly, the error happens only on NOT ODATA API.

from swashbuckle.odata.

ok. I'll work on excluding web apis from this feature.

from swashbuckle.odata.

What exactly you mean for excluding web apis from this feature?

from swashbuckle.odata.

Well, limiting the object graph is currently a 'feature' based upon this issue: only the top level properties are displayed in the swagger model, similar to how OData returns data (if you don't $expand the relationships).

So I could go one of two ways:

1. Make this feature configurable such that it can be completely disabled for both OData and WebApi routes.
2. Only apply this feature to OData routes.

Thoughts?

from swashbuckle.odata.

Rich,
I think that the issue mentioned in your post is not a real issue but a missed use of DTO's.

I would suggest to remove this limitation or waste case make it configurable for each controller type oData or WebApi.

from swashbuckle.odata.

OK. Will think about it. One issue I've found with OData is that it doesn't nicely support the use of DTOs like WebApi does; i really wish it did. I think Restier is trying to help with that. For POSTs and GETs plain OData requires the full entity and thus pulls along all of its relationships which can be extensive especially if you have a normalized entity data model.

I couldn't figure out how just limit the swagger graph to 2 levels deep so at this point it's all levels or only 1 level...

from swashbuckle.odata.

Using this solution I can use DTO's in .NET without any problem:
http://www.briankeating.net/post/WebAPI-OData-DTO

from swashbuckle.odata.

@lakeba Cool! Thanks for the link. This is off topic from this issue, but your same OData controllers support a complete set of HTTP methods, GET, POST, PUT, etc, within the same controller? I typically have different DTOs for POSTS vs PATCH, for example, as some data can be created but not modified. I can do this easily with WebAPI...

from swashbuckle.odata.

OK. Here are my current thoughts: Swashbuckle.OData should, by default, support the idiomatic or "default" usage of OData which at this point is full entities rather than DTOs. DTOs is an atypical usage of OData (although I do like the DTO approach).

So I think it makes sense to

1. Assume full entities for OData controllers and only display top-level properties by default,
   but
2. Provide the capability via configuration to display the full graph for OData controllers.
   and
3. Assume DTOs for WebApi controllers and display the full graph by default

Thanks.

from swashbuckle.odata.

Hey @lakeba, items 1 and 3 are now implemented in v2.9.3 and should fix your issue. I'll see if anyone asks for item 2 (or provides a pull request!) before implementing.

from swashbuckle.odata.