I'm integrating my java application with a service that uses json:api specification.
It has rather complex responses due to some service information(links, page info, relationship etc). The problem that I faced is that creating corresponding DTOsfor all the service info plus payload so that jaxb can map that adds a lot of complexity.
As a client I use Spring RestTemplate that is responsible for performing requests and getting response. I need to be able to map the response in a way that all the objects are mapped into appropriate DTOs and service info is also available so that I can use it for making further requests.
I was thing about several options here:
Making parameterized class that can hold different types of payload and also provide service info.
Parsing sections manually(extracting payload and service info) and setting it to some object that holds both - payload and service info.
Using external library to serialize/deserialize data. Here I found several options: winterchord/jsonapi and jasminb/jsonapi-converter.
What approach is more common and applicable for solving this task and having reliable, but still light-weight solution?
Related
I'm used to integrating with SOAP Webservices where the wsdl is accessible and can be used to generate a java client using wsimport. I've recently been given a RESTful end point which uses XML as the payload type. So far as I can see there is no WADL\ Swagger YML file I can access to get a definition of the service.
All I know so far is:
1. The endpoint
2. It operates behind HTTP basic auth
3. It accepts a POST
4. The 3 test XML payloads I have all seem to "work" returning an XML response relating to what I am trying to do
5. The URI does not change depending on the the action I am perform, the service reacts differently based on varying XML input (the request contains a payload-id attribute which seems to indicate the type of operation being performed)
From the above the service doesn't seem very "REST-like" it could just be a process listening on port for a specific request and doing crude string manipulations to parse values and then use string concatenations to crudely build a response. I get that for the most part REST is just that at a low level but I am hoping to somehow manage the apparent crudeness of the service a bit better.
How I can generate a "clean" Java client for this service (something akin to what can be done with wsimport) given that I have the XML sample requests for the 3 different operations that appear to be exposed?
For the above I was thinking that I'd somehow need to create the WADL\ Swagger YML myself, or perhaps there is a tool which could use the requests I have to build these definitions dynamically?
We eventually went for using the Feign which is a Java to HTTP client binder. It's Netflix OSS but seems to be an older library (osslifecycle=archived).
Wrapping the HTTP service was extremely easy as it only has one URI which we POST an XML payload to. We received XSD's from the service owner which we have converted into JAXB object which are then marshaled and un-marshaled within the Feign call. Feign has a concept of encoders and decoders which you can use to write your own mappers or use a provided mapper (JAXBEncoder\ JAXBDecoder).
I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.
The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,
In my company we are starting to use web services. My plan is to provide access to services via 2 protocols, http and jms. Any external access (clients outside company network) to services will be typically via http and json through a restful URL, but internally if the service needs to invoke another service, it will do it via jms, mainly to decouple the service from each other.
My question is following
Can camel provide abstraction so that i can write my service code without http, json and jms dependencies? I would like camel to handle http to java, json to java and jms to java conversion through some mediation and invocation of my service should be simply through a java method with accepts a java object as a request. Keep in mind that although http is synchronous model, jms would have to simulate request-response. If yes, can you please point me towards an example which demonstrates this setting.
Likewisely, i would like camel to convert the response from my service, which would be a java object, into json and return the response back to the client.
Lastly, how can i scale in this model. For JMS, it is easy to startup multiple instances and have them listen to a queue. How can i leverage same instances to loadbalance across http interfaces? I would like services to have location transparency, hence, they should not have to care about invoking "jms" specific cluster vs "http" specific cluster?
I think you can achieve all of this with Camel.
Marshalling between different object representations is handled through data formats. You can call POJOs from within Camel routes that can encapsulate your services.
See data formats.
Camel comes with clustering and load-balancing support. But if you only have HTTP type endpoints to load balance, then my personal opinion is that you should use a more http-centric approach, like using httpd as a reverse proxy/load balancer.
I have been seeing SOAP is "Heavy Weight" and REST is "Light Weight". On what parameters, we are telling REST is lightweight than SOAP?
We were using IFW model web services in our company earlier. But our management told us to develop all the new APIs going forward in REST. We are backend service providers in my company.
How REST is best useful for us?
What does "lightweight" means in context?
This question seems like repetition but don't understand the terms used.
REST gives you a session less window into a system. It does not track you, it does not care about you. All you have done is send a request which contains..hopefully some id to verify that you can make it. It may return a HTTP status code, it may return some body but ultimately, once the request is complete you are forgotten.
SOAP is heavy in a sense that it describes a "contract" between the remote system and your client. In order for your client to communicate effectively it MUST implement its schema...this is the SOAP skeleton. It describes the calls you can make and the objects you can expect back.
The reason why SOAP is heavy is because of serialization. Upon each SOAP request you typically serialize a java object, send it over HTTP and get a serialized response which is deserialized into an object via reflection...this is heavy. It also means that if the endpoint changes how they work, you must change your contract. You don't have to do this with REST.
With SOAP you run into multi threaded issues.
To answer quickly..
they might mean that a REST service is "lightweight" because you do not need to release changes to clients. You simply make changes to your logic, retaining URLS and the response should remain the same.
With SOAP...if you added a new field to an object, you would have to get the client to implement the new schema. SOAP is pretty old had.
REST is lightweight in that it and relies upon the HTTP standard to do its work. It is great to get a useful web service up and running quickly. If you don't need a strict API definition, this is the way to go. Most web services fall into this category. You can version your API so that updates to the API do not break it for people using old versions(as long as they specify a version). REST essentially requires HTTP and is format-agnostic, so you can use XML, JSON, HTML etc).
But the SOAP will wrap the structure into a SOAP envelope (follows an XML standard). The complexity of the SOAP envelope is based on the used message version and additional Web Service protocols. SOAP is generally transport-agnostic, meaning you don't necessarily need to use HTTP.
It can be pointed out that SOAP was designed for a distributed computing environment whereas REST was designed for a point-to-point environment.
I wonder if it is OK to say that while SOAP gives more security, REST-based API s will be easier on the resources and more scalable? As an example, Twitter, Facebook, Google Drive, Blogger, etc all have REST-based APIs that clients can consume.
Generally REST reduces the size and scope of request payloads by mapping request semantics to the underlying HTTP protocol. For example, SOAP will usually add an envelope (of varying complexity) which utilizes a WSDL (a contract) for both request and response types and service mappings. REST will just use POST, GET, etc to a URL with some HTTP encoded parameters and thus lacks an enforced contract.
There are several aspects of lightweight. SOAP is XML only, while REST allows you to send any payload, such as JSON which is less verbose and simpler than XML. Generally speaking, it takes less memory and less bandwidth to deal with JSON than XML.
On another level, using SOAP you typically describe everything as services. So, you need to define a message schema/structure for each verb and noun i.e. "CreateOrder". In REST, you use the predefined HTTP methods such as POST and put the noun/"resource" in the URI which uses already existing constructs on the HTTP level - not reinventing them in XML.
Then there is the effort it takes to adapt to change. A small change in SOAP requires you to redefine the schema, redefine the wsdl and handle versions. In rest, in the best of worlds, there is a degree of dynamic coded into the API (links to referenced resources, among other things), so that some changes can be implemented and takes effect directly.
All the heavy weight strictness of SOAP of course has a valid reason for existence. It's less likely two implementations have different interpretations of the API, than in a loosely defined REST API. SOAP also allows you to implement skeleton code in various languages based on a WSDL. In some complex scenarios, this is actually almost the only productive way to work with SOAP. Marshalling and unmarshalling between objects and serialized XML is rather heavy and adds to the heavyness of SOAP.
I have a prototype for a RESTful web service using Apache CXF. I am using json for the data exchange between client and server. currently there are several pojos which are mapped to several request and response JSON needed for different scenarios.
My concern is, if the number of scenarios increase in future we will have to additional pojos for request and response. Is there any other way of doing it?
Are all these pojos have same type of behavior??? if yes then we can create an interface, all pojos should implement this interface. We can initialize object at runtime based on pojo class name.
you can use this code for runtime initialization. -
INTERFACE_CLASS_NAME interface_identifier=(INTERFACE_CLASS_NAME)Class.forName(POJO_CLASS_NAME_WITH_PACKAGE).newInstance();
You can use third party library like Gson to convert pojo to json or vice-versa.