ReadTimeout ( number) The timeout on waiting to receive data, in milliseconds. Headers ( object) HTTP headers, an object where the keys are header names and the values the header values.ĬonnectionTimeout ( number) The timeout on establishing the connection, in milliseconds. Will not be used if queryParams is provided. Params ( object) Form parameters to be sent with the request. QueryParams ( object) Query parameters to be sent with the request. Method ( string) The HTTP method to use for the request (e.g. Ps.Url ( string) URL to which the request is sent. The last requirement, but certainly not the least important, is that I need all interfaces of the library to be annotated with This is important because I need to be able to encapsulate an instance of Request in other immutable classes. None of the libraries that I’m aware of or worked with offer this feature. The same can be done with JSON through the Java JSON API ( JSR-353). This then exposes the xml() method that returns an instance of the XML interface. get ( 0 ) īasically, the response produced by fetch() is decorated by XmlResponse. For example, you can fetch XML and retrieve a string value from its element: String name = new JdkRequest ( "" ). Jcabi-http client supports them both out of the box, and it’s possible to add more formats in the future as needed. It has always been a hassle, and extra work, for me to parse the output to take care of formatting issues. In most cases, the response retrieved from a server is in either XML or JSON format.
There are two common standards that I wanted the library to support right out of the box. fetch () page = new ApacheRequest ( uri ). These two calls perform the task differently, but the end results are the same: String uri = "" Response page page = new JdkRequest ( uri ).
Say, for instance, I want to fetch a page and then do something with it. In the future, it will be possible to introduce new implementations without breaking existing code.
For example, we have JdkRequest and ApacheRequest, which make actual HTTP calls to the server using two completely different technologies: (JDK HttpURLConnection and Apache HTTP Client, respectively). Use of interfaces makes the library highly extensible. Request is an interface, as well as Response, RequestURI, and RequestBody exposed by it. In jcabi-http, there are five interfaces extended by 20 classes. I’m a big fan of interfaces, mostly because they make your designs both cleaner and highly extensible at the same time. To my knowledge, none of the existing libraries enable this type of fluency. Why is this important? I think that fluent interface is the most compact and expressive way to perform multiple imperative calls. The new client has to be fluent, which means that the entire server interaction fits into one Java statement. The Alternative to Fluent Interfaces in Java (webinar #33) 4 April 2018. I assume that the above is easy to understand and maintain. header ( "Accept", "application/json" ). For example, this is how I use the new client to return a current EUR rate: String uri = "" String rate = new JdkRequest ( uri ). In most cases, I need only to make an HTTP request and parse the JSON response to return a value. The client must be simple and easy to use. I designed this new client with the following requirements in mind: Simplicityįor me, this was the most important requirement. Still, this is how my jcabi-http client interacts when you make an HTTP request and expect a successful HTML page in return: String html = new JdkRequest ( "" ). Nevertheless, I decided to create a new one because none of the other clients satisfied fully all of my requirements. In the world of Java, there are plenty of HTTP clients from which to choose.
0 kommentar(er)
