What is the requirement for the “Add ServiceStack Reference” to work? The REST server part is developed in Java and i was wondering if I could use the Add ServiceStack Reference to generate c# code.
Don’t think I understand the question, but all Add ServiceStack Reference does is generate your C#/.NET DTO’s into different languages which is all that’s needed to call ServiceStack when using the generic service client for each platform.
Not seeing how this will be useful for a Java REST Server, since the DTO’s need to be in C#/.NET + ServiceStack.
But based on what metadata/standard is the ServiceStackVS creating the C# code (or whatever client code)? Swagger? JsonSchema? or …?
It’s not based on any metadata standard, ServiceStack does all the source code generation itself which is how it’s able to provide rich clean models with attributes, interfaces, comments that are also highly customizable.
The master authority of truth is your C# models, all other language projections are based off that.
Just to clarify further, ServiceStackVS and all other IDE plugins/addins etc are just calling the appropriate language path for the specific IDE/environment/context. Plugins just check project type/dependencies/other context info in the IDE to provide a sensible default.
Would it be possible extend the current implementation to generate a json servicestack client from a swagger.json definition?
We already have a solution that works best for ServiceStack, building off the JSON output from we give to Swagger UI would be inferior in every way.
Yes, i know. But the server part is not built with servicestack, but with a java REST server that outputs a swagger.json for the definition…If servicestack can create a swagger definition, maybe it’s also an option to generate a client based on a swagger.json definition.
Turning Swagger .json is something you would use Swagger’s Code Generators to do, ServiceStack is focused on providing a great development experience for consuming ServiceStack Services.
Yes, but those Code Generators generate HttpClient code with a lot of helpers classes. Replacing them with JsonServiceClient from servicestack would be much easier…
Which is how JsonServiceClient is easier to use as we’re able to generate DTOs directly and control the native Service Client libraries to support generated DTOs and ServiceStack endpoints. Trying to derive the same functionality by forcing it through an interim Swagger .json format yields and uglier, more complex and more limited interop library.
I got the feeling you still dont completely understand me. I’ve got a swagger definition file and i want to convert it into a JsonServiceClient implementation so i can use all the benefits of the servicestack Client… so instead of generating from the super servicestack server DTO/servies, it could generate code from the minimal swagger json (of maybe even a JsonSchema defintion)
I understand what you’re asking and have already responded.
There is no reason for us to generate DTOs/Service clients off swagger JSON spec. We’ve already have an end-to-end solution that’s more elegant for ServiceStack. We would not consider investing effort in a solution that would go through a Swagger (or any other 3rd party) specification format - it’s far too limiting and yields an ugly and unnecessarily complex result, i.e. you wouldn’t get the same development experience going through Swagger JSON.
There are already solutions that generate clients from Swagger - this isn’t something we’d dedicate the resources into copying ourselves. JsonServiceClient is opinionated in consuming ServiceStack Services, you’ll need to use whatever library your 3rd Party API recommends to consume their Services. The solution we use for consuming 3rd Party APIs is HTTP Utils for which we have a live demo of on Gistlyn.
Ok. Clear! I thought it could be a nice extension for the servicestack. Thanks for your time.