I realized that when I try to access one of the paths defined in my swagger 2.0 with an incorrect method (ie. GET instead of POST), I receive the following message:
{
"message": "Route defined in Swagger specification (/myPath) but there is no defined get operation.",
"allowedMethods": [
"POST"
]
}
The error message is the same described in this post but my question is quite different. How to get rid of the error in swagger - there is no defined post operation.
I don't want that info to be shown even if I'm not calling to the right method.
I've been looking for any kind of configuration that could remove the "allowedMethods" object from the response. I know this is not the end of the world but I would like not to give away any info about which methods are allowed and which aren't. As a plan Z, I've considered defining any other method for every route with an empty response but that seems a bit overkill, don't you think?
Edit: Server is Nodejs.
Related
While designing a GET endpoint I am confused ...
Have designed Open API spec 3.0 for successful response ( 200 ) , invalid request ( missing mandatory stuff ) ( 400 )
Now I am confused about things like : 401 ( Unauthorized ) , 405 ( Method not allowed ) , 415 ( Unsupported Media type )
This API will need an api key to be provided in header and if not provided by user or an invalid api key is provided then they should get a 401
So I think I should be specifying 401 in my response spec .
However when I look at swagger's Pet store ( https://editor.swagger.io/ ) they are not having this response code anywhere ... ?
My API spec ONLY supports GET with Content-type : application/json so I am thinking we dont need 405 ( DELETE / POST / PUT etc ) .
Similarly if consumer sends application/xml or anything other than application/json we are not supporting it so this is why we should not be explicitly defining 415 in the spec ?
A bit confused which is why am looking into some inputs.
Was referring to some pages here and here
I think it is a good idea to document the Response Codes the API might return, it is indeed supported (but optional) by OpenAPI.
The consumers might find useful to know 401 Unauthorized means the JWT token is not supplied or it is expired, or 400 means the payload is incorrect (i.e. missing a specific attribute).
Check this example if you would like to see how Response Codes are documented and displayed by Swagger UI.
However when I look at swagger's Pet store they are not having this response code anywhere ... ?
The Pet Store is really just an example that one can use as a starting point or when you want to feed a tool with a sample spec. It is not meant to be normative. If you look through the sample code, you will even find paths which are RPC style (e.g. here) and other things that are not exactly RESTful.
why we should not be explicitly defining 415 in the spec ?
I think the blogposts that you found are helpful and do not contradict each other. Both of them rightfully recommend you to use the standard http response codes and provide a helpful error body. Some people omit response codes that they think are self-explanatory. But IMO, adding these few lines is totally worth it. If you add them diligently, then you get a key aspect of openapi right: The purpose of openapi is clarity and predictability of the capabilities and behaviour of your API.
So in summary: Yes, think about the responses that you are going to need, and do include these response codes in your api spec.
I am building a web api on asp.net. I make requests through client and server. GET and DELETE methods are working properly. When i make POST or PUT i get an error "Response status code does not indicate success: 500 (Internal Server Error)."
Client:
Server:
I used this tutorial.
Why i get a null object (Employee)?
If AddEmployee is an endpoint, then you may need to put the [FromBody] attribute on the parameter.
If it's not an endpoint, then I don't see where AddEmployee is being called. But it looks like the employee parameter is the one that is null. Look up the stack trace, and I bet you'll find someplace where employee is not being set.
I dont know how but when i built a new project the error dissapeared... I used the exact same files and classes.
I am very new to web api stuff:
I am getting an error
406: Not Acceptable
error message in asp.net web api rest service.
In my rest service I’m using media format for my customized XML output, to get customized output.
I’m registering my formatted media in Global.asax page.
GlobalConfiguration.Configuration.Formatters.Clear();
GlobalConfiguration.Configuration.Formatters.Add(new mynewformat());
all my methods are post methods with typed object as parameter and parameters are accepts from body.
Whenever I try to test the service… Getting 406: Not acceptable error message.
can anyone please help me ... what could be the reason for this....???
I did notice couple of interesting points here...
If I’m commenting below line then I’m getting 200 (OK) status code (which is fine.)... but format is not applying to output.
GlobalConfiguration.Configuration.Formatters.Clear();
If i'm removing parameters in my service method.. Then its working
fine..
I request everyone.. Please guide me what could be the reason/work around/solution/fix..for this issue.
Note:I don't want accept parameters from URI so i made it to accept from frombody only.
Thanks.
There is a lot more to implementing a custom format than just adding it to the configuration formatters. It starts with having to change the media-type header to a new custom type of your choosing (like "application/myNewFormat") for all requests, for the client. On the back end, you have to implement a new MediaTypeFormatter that can handle the serialization. This involves a bit more of code.
A good example of this resides here, it can easily be stripped to boiler-plate code:
http://www.codeproject.com/Articles/559378/Implementing-Custom-Media-Formatters-in-ASP-NET-We
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is
only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't
strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than
"getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues)
the side-effects of N > 0 identical requests is the same as for a single request. The methods GET,
HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the
same resource. So, regardless of the entity body present as part of a GET request, the side-effects
must always be the same. In layman's terms this means that if you send a GET with an entity body
100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must
have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy
of a method and its resulting side-effects.
In case of GET Method
Appends form-data into the URL in name/value pairs and length of URL is limited(3000 characters).
File content can't be put inside a URL parameter using a form.So use POST
In Get method, the value of action, appends a `?' to it, then appends the form data set, encoded using the "application/x-www-form-urlencoded" content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
So, that file upload is not possible in GET Method
I've been dealing with a "soap message header incorrect" error message when submiting a SOAP request using Savon.
I copy/pasted the exact same xml generated by Savon into SOAPUI and I don't get that error and I get the expected response.
So, since I'm tired of trying different things, I want to assemble my own header without Savon help on that.
What I want to do is something like:
soap.header = "<wbs:Session><wbs:SessionId></wbs:SessionId><wbs:SequenceNumber></wbs:SequenceNumber></wbs:Session>"
However I get this error from Savon:
can't convert Symbol into String
Why?
Thank you in advance.
Its likely caused by the fact you havent set any values.
I was getting this error when I had a hash containing just one custom object on return, as it was trying to access parts of the hash that had automatically been removed. (it removed unnesscary layer of hash for me :#)
I believe the header will only accept a Hash - from the savon.rb page:
Besides the body element, SOAP requests can also contain a header with
additional information. Savon sees this header as just another Hash following
the same conventions as the SOAP body Hash.
soap.header = { "SecretKey" => "secret" }