Is it bad practice to modify a generated Swagger Client? I am trying to de-serialize a dictionary of long, strings which I know isn't technically supported. Is it bad practice to "hack" the generated Swagger client to support this?
It seems like from people I’ve talked to it’s not a huge deal to do this.
Related
So I currently already have the swagger UI set up with the page and everything, but I want to edit the .json file (so I can provide descriptions, error codes and stuff but all in one document). Was just wondering where I should be locating my swagger.json or swagger.yaml file to be able to adjust the API??
If not, what's the best practice for documenting parameters, response codes and descriptions WITHOUT having to do it tediously one by one like below...
Any advice on using swagger with nestjs applications would be much appreciated :) Still very new with using it
I'm looking for a starting point on how to extend BreezeJS (or if it's even possible!) to support sending JSON data using the Badgerfish notation to the server from BreezeJS.
I see that BreezeJS has the JsonResultsAdapter - to take a response from the server and transform it - which would work to allow Breeze to walk through a Badgerfish JSON result set and instantiate entities.
I need the other way - a JsonRequestAdapter (or something like it) - to take the JSON that Breeze has created and about to send to the server, and modify to the Badgerfish notation.
Any guidance for this problem? thanks!
Update: June 2013
I've gone with the approach of implementing a custom Breeze DataService adapter that I pass into an EntityManager instance. This approach is not for the faint of heart to be honest, and took some work to really understand what needed to happen. I took the provided Web API DataService adapter and 'adapted' it to work for a generic RESTful service.
Adam, this is a great question.
We are trying to come up with a standard mechanism analagous to the 'JsonResultsAdapter' to be used to intecept http 'puts' but really want to understand the most common use cases first. We'd love any feedback on suggestions and use cases.
Please add a 'feature request' for this to the Breeze User Voice. We take these suggestions very seriously and this is a topic that we think is important as well, but really want to get some feedback from our community on its priority.
I'm trying to build some RESTful services using spray. I've figured out how to build the directives I need. But the issue I'm having is how to reliable generate URLs back to the "resources" I'm working with. Note I use the term "resources" here as it is used for RESTful APIs (i.e. the server side objects one refers to through the API).
I've looked through the documentation and I haven't found any reference for this except mention of "Resources" in the Java sense (i.e. data files in the classpath).
For sure I can build a directive that maps "/items/127" to a resource on the server side. But what I don't see how to do (at least in a safe and automatic way) in Spray is how to generate such a URL given the server-side resource. I'm looking for something similar to url_for from the Flask framework.
For now, I'm writing functions to do this. But, of course, they are fragile because they aren't DRY (i.e. they don't use any knowledge of Spray routing in generating the URLS).
Am I missing something?
What you're asking for is known as reverse routing. As #iwein said, there's no direct support for reverse routing in Spray. You can confirm this from Matthias in this thread. There is an open ticket for this issue.
However, there is an approach, based on the PathMatcher that Marcel Mojzis open sourced which you can find here.
I have a need for this as well, but I'm going to get by with a "known pattern" approach until Spray (or akka-http) comes up with its own solution to this issue. Essentially, I have an object that knows how to generate the URL for certain patterns of things. Each pattern is a function and clients of the object have to ask for the url by one of the function names. Not ideal, but very simple and effective until akka-http provides a more generic solution.
I don't think that Spray has an equivalent of url_for. I don't think it would make sense in the context of Spray, because in Spray you're not annotating functions with urls that map to them, but you're creating routes that deserialize requests and eventually map them to functions.
As such there is no easy way to generate an example url from the name of a function.
I am confused about the current framework for a client/server architecture system.
You know, when we are writing a small demo, on the server side, we listen on a port and establish a TCP/UDP connection with client, after that, we do some customize work.
Well, my question is, when we are using a framework like Ruby on Rails, where can I put my customize work?
It seems these frameworks are just for people managing a website.
I can't add a comment, so some words more here.
Thanks for your answers. Actually, I know how to do socket programming to handle all the requrest. But since what I want to build is a product not a demo. I think a wide-used framework is what I need.
ACE and twisted seem good to do these things. But what about RoR? I saw many websites that you can use their APIs and get messages from their servers. Can't RoR do these things? If so, how can I implement HTTP + JSON communication between client and server without having a website page?
I checked several tutorials on RoR, they only told me how to build a website to present HTML files, but what I need is a mechanic to communicate between Server and Client.
Thank you.
Ruby on Rails is indeed designed for implementing a website or other HTTP-related things.
There are other frameworks out there for doing more generic server implementations. For example: ACE and Twisted.
Not sure I understand exactly what you're asking but it seems like you're looking for the Ruby sockets framework?
http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm
Is a pretty straightforward description of how to do basic port listening/reacting.
I assume you are looking for an explanation of where cusom code goes when the server is mostly built from reusable pieces coming from a framework.
Forgetting about Rails for now, many older, simpler frameworks started life as a simple way to build objects to represent the incoming request and the outgoing response on the server side. From there, your custom code would be in making decisions about what to do with the request, and what to write to the response.
A more complex framework may include a templating engine, which makes it easier to put a complete response together by filling in the blanks (like a user name) in an HTML template, avoiding the need to manually craft the whole HTML response in the server code.
A lot of modern frameworks allow you to write applications like this, and many provide other pieces of functionality to make common coding patterns quicker and easier to write.
In my ASP.Net MVC 2 application I am using a Json object to submit form data. I would like to take expert advice whether it is a safe and good practice to do it or not and why? Please note, this question is not about how to do it but rather about best practice. Appreciate your valuable suggestions.
Yes it is safe to send and receive JSON from/to the server. You only need to make sure to properly format and encode it. Whether it is good is subjective and will depend on your scenario. As JSON is a common format for javascript it is used along with AJAX requests.
I think it's a safe way to go.
I don't think there is much difference (for security reasons) to send the data via a regular post or a Json object submit.
In both cases the data is wrapped into a http post request which is a readable thing.
So i think both solutions are equal from a security perspective.
As said above, JSON is fine to use going both ways, provided you are still applying the same validation as you would with any form input.
Personally, I love the ability to make AJAX calls and simply do:
Return Json(myDataObject)
Then it's really easy to process that with jQuery on the client side as it's automatically transformed into javascript variables for you.