I have customized Apache Wink to use an XML provider, basically overriden the standard JacksonJsonProvider.
See http://jackson-users.ning.com/forum/topics/jackson-xml-provider for details
The provider seems to work and the resource gets correctly recognized, but the resource method does not get executed.
Do I need to set something on the client ? Apache Wink returns HTTP 204 (No content).
The problem turned out to be the resource signature mismatch. By default, the rest client which I was using used an "accept" text/plain by default whereas the resource was returning "application/xml"
Related
I have the below in my Dropwizard conf file as a generic size limitation on all incoming API calls. I have a callee that is going through a proxy and the proxy strips the content-length header from the call. For now the proxy cannot be fixed so I need a work around. The Dropwizard validator rejects incoming calls without a content-length header even if the actual content is non-null. For one and only one particular API I'd like to make an exception and allow an incoming API call without a content-length header. If I comment out the limits below in the conf file then any incoming API call without a content-length header works but that solution opens a security hole.
Is a custom validator my best option? Are there other options? Will the custom validator override the generic validation or will the generic validation still reject the API call without a content-length header (i.e. is validation an AND or an OR operation with generic and custom validators in place)?
contentLengthLimit {
maxContentLength: 8388608
maxContentLengthToRead: 52428800
}
# Sets the limit for request content length after decompression for gzip request, to
prevent zip bomb.
# https://en.wikipedia.org/wiki/Zip_bomb
# Add a value larger than your expected uncompressed object sizes for your API to your Application's config
# If the limit is null, the ZipBombPreventingFilter filter will not be registered.
contentLengthLimitAfterDecompression: 8388608 #8MB
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.
Does anyone know how to pass parameters to a RESTFUL webservice using the Orbeon HTTP Service?
I have a RESTFUL API at http://localhost/RESTFUL/GETADDRESS/$parameter$.
Sample of the URL is http://localhost/RESTFUL/GETADDRESS/1234
Orbeon HTTP service is unable to pass the parameter to the web service.
The Request Body is configured as <parameter/> and serialization is set to XML.
Could not use HTML Form as it adds a ? to the URL which is not correct.
Anyone has any ideas to get this working?
There is no perfect solution. But try writing the service URL as:
http://localhost/RESTFUL/GETADDRESS/{...expression here...}
where "...expression here..." should be replaced by an XPath expression pointing to the value you would like to pass. For example, if pointing to a control called foo in a section called bar, try:
http://localhost/RESTFUL/GETADDRESS/{/*/bar/foo}
I also added this RFE.
What error format must be used by RESTful API when content negotiation fails (ActionController::UnknownFormat is raised):
when a controller responds to the only one format (e. g. JSON) and the user has requested another one (e. g. XML), should the error be generated as JSON object or XML one?
when a controller responds to several formats and the user has requested neither of them, which one should be used during error generation: one of the 'known' by the controller or the one, having been requested by the user?
I think you are under no obligation to respond to any invalid request with the same format as the request was made. Imagine getting a request with payload in unknown binary format - what are you supposed to do in such a case.
ActionController::UnknownFormat should trigger a 406 Not Acceptable response, probably will in Rails 5.
You should rescue the ActionController::UnknownFormat and respond with proper HTTP code as well as set an Accept header listing all formats that your API supports (if Rails doesn't do it by default, I'm not sure)
Im getting this error:
(a:6016) The message with Action 'xxx'
cannot be processed at the receiver,
due to a ContractFilter mismatch at
the EndpointDispatcher. This may be
because of either a contract mismatch
(mismatched Actions between sender and
receiver) or a binding/security
mismatch between the sender and the
receiver. Check that sender and
receiver have the same contract and
the same binding (including security
requirements, e.g. Message, Transport,
None).
And I noticed that the binding used by my provider's WSDL is:
BasicHttpBinding_IxFlow
I guess I need to specify that in my Savon Controller. How can I do that?
Thx.
Since the error message is not really helpful (received this one for various errors) here are some suggestions:
try calling the service (or just generate the xml) from another client and record the XML
compare with Savonrb XML (it prints it to the console, not pretty formatted but good enough)
send the XML you captured from another client trough savon. Does this work? (you can specify custom XML with the block version of client#request method)
Look at (this was the problem with my service):
Order of parameters
Namespace of parameters
SOAPAction header (you can also specify it in the block version)