I develop a rest endpoint in camel and would like to provide the following PUT - Method /service/createObject/{objectId} which also accepts a payload.
If I configure a mehtod like this, the payload will be overridden with the path parameter {objectId}. Is that the default behaviour and can I change it?
Related
Using openapi-generator to generate a C# API client using an openapi v3.0 specification. Is there a way to customize the methodNames of the API? I'd prefer to be able to specify them maybe by using operationId field?
Right now they are incorporating the path variables along with the HTTP VERB and the static path components. It'll work, but I'd like the names to be a bit different.
GetEncountersResponse ClientidEncountersDateGet (string clientid, string date, string startToken = null);
The other option is to just add new methods since the class is defined as partial?
Right now they are incorporating the path variables along with the HTTP VERB and the static path components. It'll work, but I'd like the names to be a bit different.
Looks like the operationId (optional) is missing in the operation (endpoint) defined in the OpenAPI doc/spec and that's why the method name is auto-generated based on the path, HTTP verb, etc.
You can define the operationId to have better control of the method name.
I know fieldWithPath() has optional() but didn't find how to make parameterWithName() optional.
In Spring REST Docs 1.1 you can mark request and path parameters as optional. If you want that information to also appear in the generated table you can use a custom snippet that adds the optional column (once this bug has been fixed).
In Spring REST Docs 1.0 you can't mark a request parameter as optional via a first-class API. I would recommend using a combination of a custom attribute on the parameter descriptor and, if necessary, setting the ignored flag on the descriptor to allow the test to pass in the parameter's absence.
I am creating HTTP request using Apache HTTP Client version 4.3.4. I see there are some classes like HttpGet,... and there is also a class BasicHttpRequest. I am not sure which one to use.
Whats the difference and which one should be used in which condition ?
BasicHttpRequest is provided by the core library. As its name suggests it is pretty basic: it enforces no particular method name or type, nor does it attempt to validate the request URI. The URI parameter can be any arbitrary garbage. HttpClient will dutifully transmit it to server as is, if it is unable to parse it to a valid URI.
HttpUriRequest variety on the other hand will enforce specific method type and will require a valid URI. Another important feature is that HttpUriRequest can be aborted at any point of their execution.
You should always be using classes that implement HttpUriRequest per default.
I was just browsing the 4.3.6 javadoc attempting to locate your BasicHttpRequest and was unable to find it. Do you have a reference to the javadoc of this class?
I would be under the impression that BasicHttpRequest would be a base class providing operations and attributes common to more than one HttpRequest. It may be extremely generic for extension purposes.
To the first part of your question, use HttpGet, HttpPost etc for their specific operations. If you only need to HTTP/GET information then use HttpGet, if you need to post a form or document body, then use HttpPost. If you are attempting to use things like the Head, Put, Delete method, then use the correspoding HttpXXX class.
I'm having two rest methods as follows
/objects/(int:type)/(id:objectID)/(ver:version)
/objects/(int:type)/(id:objectID)/(str:version)
if i send the request as like the following URI
http://localhost/REST/objects/0/123/latest which of the above method gets called.
whether the 2 methods are same or different.
need to know what are all the parameter types available and what is the actual usage of each type.
And how the URI identifies the exact method
That question is all about the server framework you are using and nothing about REST. REST says nothing about URI structure, and certainly nothing about how URIs are mapped to handlers.
I have a Java client that calls a RESTEasy (JAX-RS) Java server. It is possible that some of my users may have a newer version of the client than the server.
That client may call a resource on the server that contains query parameters that the server does not know about. Is it possible to detect this on the server side and return an error?
I understand that if the client calls a URL that has not been implemented yet on the server, the client will get a 404 error, but what happens if the client passes in a query parameter that is not implemented (e.g.: ?sort_by=last_name)?
Is it possible to detect this on the server side and return an error?
Yes, you can do it. I think the easiest way is to use #Context UriInfo. You can obtain all query parameters by calling getQueryParameters() method. So you know if there are any unknown parameters and you can return error.
but what happens if the client passes in a query parameter that is not implemented
If you implement no special support of handling "unknown" parameters, the resource will be called and the parameter will be silently ignored.
Personally I think that it's better to ignore the unknown parameters. If you just ignore them, it may help to make the API backward compatible.
You should definitely check out the JAX-RS filters (org.apache.cxf.jaxrs.ext.RequestHandler) to intercept, validate, manipulate request, e.g. for security or validatng query parameters.
If you declared all your parameters using annotations you can parse the web.xml file for the resource class names (see possible regex below) and use the full qualified class names to access the declared annotations for methods (like javax.ws.rs.GET) and method parameters (like javax.ws.rs.QueryParam) to scan all available web service resources - this way you don't have to manually add all resource classes to your filter.
Store this information in static variables so you just have to parse this stuff the first time you hit your filter.
In your filter you can access the org.apache.cxf.message.Message for the incoming request. The query string is easy to access - if you also want to validate form parameters and multipart names, you have to reas the message content and write it back to the message (this gets a bit nasty since you have to deal with multipart boundaries etc).
To 'index' the resources I just take the HTTP method and append the path (which is then used as key to access the declared parameters.
You can use the ServletContext to read the web.xml file. For extracting the resource classes this regex might be helpful
String webxml = readInputStreamAsString(context.getResourceAsStream("WEB-INF/web.xml"));
Pattern serviceClassesPattern = Pattern.compile("<param-name>jaxrs.serviceClasses</param-name>.*?<param-value>(.*?)</param-value>", Pattern.DOTALL | Pattern.MULTILINE);