I have a swagger API that I am generating client and server code from.
The client code uses the 'Angular Typescript' option; the server uses the 'node.js' option.
The problem I am having is that the client code models' properties are being generated in camel case (e.g. firstName) and the server models' properties are being generated as pascal case (e.g. FirstName).
The models I have defined inside the spec use pascal case.
Because of the different casings, I am having issues referencing the properties.
Is there a simple way (i.e. not modifying the swagger code gen source) to have the generator respect the names that are defined in the swagger document?
It will be fixed in an upcoming swagger-codegen 2.1.6. There's a commit that allows to change property naming convention.
As a workaround you can also change your server API implementation to support the camel cased property deserialization.
Related
I'm designing a REST API (implemented with ASP.NET Web API, not ASP.NET core, because we can't upgrade it right now).
I'm looking for the best solution to partially update an entity.
For example, the "Person" entity has 100 properties, and a third party system only has to update the "PersonValidityDate".
What is the best and simplest solution to do it ?
I read some article about the PATCH verb, with JSON patch or JSON merge patch, but it seems a bit complicated and not supported by everyone... Is it ?
I'm looking for a very simple solution to do it, that any integrator can understand and use...
What do you suggest ? Is PATCH often used?
If I use POST/PUT and only give the properties to update and ignore the other properties, when the body is deserialized, nullable properties will be null. How can I distinguish the properties set to NULL explicitely and not provided properties ?
According to RFC 5789
Several applications extending the Hypertext
Transfer Protocol (HTTP) require a feature to do partial resource
modification. The existing HTTP PUT method only allows a complete
replacement of a document. This proposal adds a new HTTP method,
PATCH, to modify an existing HTTP resource.
So you should use a PATCH request for partial update of the object and PUT for complete object replacement.
And you should not use the complete model in patch request with empty/null fields instead use the new model for PATCH request.
You can check more example here
Dear all,
I am using EhCache with Spring MVC 3. My server takes json from other server, I have added cache on it. It works fine when there is no parameters. Can I cache the json based on the parameters also.
Right now I am using method name as key for caching, can I include params also ??
Here is code
#Cacheable(value="products", key="#root.method.name")
Thanks,
Dev
By default, as described in Spring's Cache abstraction, the key will be computed from the parameters.
So try first with dropping the key attribute in your declaration and see what that does for you.
If you need to tweak the key computation, have a look at the documentation.
I have 1 Site (MySite.com) / 1 Web Service (WebService.MySite.Com) and one Common Library (LibCommon)
The common Library Contains a Model e.g. UserModel = LibCommon.UserModel
The web service has a method 'Void CheckUser(LibCommon.UserModel model)'
However when I add the 'WebService' reference to 'MySite.com' the method changes so that it looks like 'Void CheckUser(WebService.MySite.Com.UserModel model)'
So I think fair enough I can just cast one object to the other as they are identical however .NET Says I cannot do this?
Is there a work around for this?
Cheers,
Note this is for WCF, and not ASMX web services:
You can't directly cast the original data class to the proxied class generated by the WCF service reference wizard. However, you can reuse the original data class in the client:
Add the library reference containing the transfer objects (i.e. LibCommon) as a reference to both the Service (WebService) and the Client (Mysite.com). When adding the service reference on the client, choose the advanced tab and then select Reuse types in referenced assemblies. This will then reuse the common data transfer classes, instead of duplicating the types with proxies.
Note however that by eliminating the proxied data class, you are introducing direct coupling between client and server - you should do this only if you have control over both client and server w.r.t. version control issues etc (e.g. able to deploy new versions of both client and server simultaneously)
As an aside, it is also possible to eliminate the shared service interface as well, by moving the server side Service contract interface into a separate, common assembly and then using a technique such as this or this.
Can someone explain the difference between the two, when to use WebScriptServiceHostFactory vs WebServiceHostFactory? I understand when used they setup certain default behaviors on the endpoints so I don't have to. Otherwise the differences, is it just the WebScriptServiceHostFactory defaults to JSON messages, while WebServiceHostFactory defaults to XML (soap messages)? Using WebGet and WebInvoke, do both work on them, or does one not allow it? Also can I use UriTemplates, to build REST services, with either one?
The WebScriptServiceHostFactory is used almost exclusively to define services that will be consumed by the ASP.NET AJAX framework (it gives the JS client a "proxy" which can be used to call the service). If you're doing general-purpose WCF web (REST) programming, you should stick with the WebServiceHostFactory.
Some differences:
As you mentioned, the default response format is different (JSON in WScriptSHF, XML in WSHF)
UriTemplates are fully supported in WSHF, not in WScriptSHF
WebGet and WebInvoke work on both, but on WScriptSHF the only supported body style is WrappedRequest
Responses to calls to an endpoint created by WScriptSHF are wrapped in a JSON object; if the response to an operation (in JSON) was [1,2,3], the endpoint will return it as {"d":[1,2,3]}.
There may be others, but essentially, the guidance is to use the WScriptSHF only if you're using the ASP.NET AJAX framework (with the <asp:ScriptManager>) and the WSHF for everything else.
I have two Biztalk applications, each of which expose a webservice port,
I'm consuming them in an ASP.NET client using the 'Add service reference' tool from within the VS2010 GUI to generate the proxies.
But the proxy interface is slightly different in both. One takes two parameters, returns the 'response' via a parameter using the out keyword and has a void return type,
the other takes one parameter and returns the response using a typed return value.
I'm confused as to what is causing the difference in behavior, is something I'm doing as part of the creation of the references (as far as I can tell I've used the same process) or is it something about the server/WSDL I'm consuming?
EDIT -As per Grahams comment the type of proxy interface generated seems to depend on whether there is a namespace or not. I'll give the answer to whoever can put together the clearest description of what exactly is happening there.
As noted in the comments, the inclusing of a namespace in one of the services is what was triggering the difference in the proxy code generation. It's still not clear exactly why this is the case however.