Scenario:
I'm working on a web services project. It supports SOAP and REST. The SOAP request and response are handled by XmlObjects. The REST architectures uses plain POJO's for request and Response. I have a common controller to handle the request from SOAP and REST. This controller understands a common object (Request Object). And , the controller sends back a Transfer Object. In front of the controller , I have a request translator to translate the SOAP/POJO objects to common Request Object. And also a response translator to convert the transfer objects to SOAP/REST view objects.
Problem:
I have 2 request and response translators. The SOAP/REST request and response translators look the same. But, they take a different object as input. So it looks like I have the same code 2 times.
How to avoid this redundancy?
Solutions that I thought of : Bean mapping.
Is there anything else more elegant than this?
I assume both your "REST" and "SOAP" APIs must do the same thing and are therefore quite parallel. You ought to (re)read Roy Fielding's description of the REST architectural approach and then decide if these APIs are truly RESTful in Roy's very precise definition of the term. If they are both RESTful, then just ditch your SOAP APIs: SOAP is harder to use, doesn't leverage HTTP caches, and adds nothing over your REST APIs.
If they are both non-RESTful (ie, they have a Remote Procedure Call flavor and the "REST" APIs just happen to do RPC operations using HTTP and XML), then assuming you can't convert them to the REST architectural style, you can at least factor out the POJO<==>XML mappings using a library like XStream.
You are right, If only the request/response XML differs in layout only and the data is same then you can make XSLTs for both of them which will convert it into proper XML as per your POJO.
Then you can use Castor mapping for XML to POJO object right? And you will get your needed object. But you have to make the object common for the code right?
What i mean is, use common object for your logic and use some another logic to get that object from your Request/Response objects for SOAP/REST. Because the data you are sending will be same in both kind of methods, you just need to handle Object to object conversion. That can be done directly OR using Object to XML and XML to object.depends which you prefer.
hope this helps.
Parth.
Related
Currently I am creating some intra-service calls among microservices. Opting to leverage google's protobuf, I am using it in unison with Spring Boot Rest APIs. And I am presented with two options.
First: Serializing the protobuf objects. It is possible to serialize protobuf objects in the REST request and have the receiving end deserialize it and perform whatever it needs, then serialize a protobuf response for the initial caller. This involves a flow of serializing, deserializing, and vice versa.
Second: Sending the protobuf object as is. It seems like a REST API is able to accept x-protobuf requests. I am wondering if this has any significant drawbacks in terms of speed?
Currently, I am employing the latter, I was wondering if anyone else who has tried this prefers one over the other?
I have a use case where some context needs to be transferred from the UI to the backend and backend needs to decide and send the response based on that context.
This can be achieved by sending the context through request body and at the server side, by parsing the request body, the representation can be sent in the response body.
My doubt is which http method is suitable for this?
GET: If we use GET, we can send the request body but it is advised that the body should not have any semantics related to the request.
See this: http-get-with-request-body
So I am left with POST or PUT but these corresponds to updating or creating a resource and using them might be little misleading.
So my question is what is the appropriate HTTP method that could be used in this scenario which is acceptable in the RESTful design standpoint.
Appreciate the response.
I am thinking to use POST or PUT as there are no restrictions on consuming the request body on the server side.
EDIT:
I think POST would serve my purpose.
The rfc HTTP RFC 7231 says that POST can be used for:
Providing a block of data, such as the fields entered into an HTML form, to a data-handling process
So the data handling process for me is the backend server and HTML Form is equivalent to any UI element.
So I can make use POST method to send the data to backend and send the existing resource representation as response body with http-status code being 200
Please bear in mind that GET must be used for data retrieval only, without side effects. That is, GET is both safe and idempotent (see more details here).
If the operation is meant to be idempotent, go for PUT:
4.3.4. PUT
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. [...]
Otherwise, go for POST, which is a catch all verb:
4.3.3. POST
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. [...]
I would go for POST because in REST, PUT is used to create a new resource like user.
There is a PATCH post method, that is for changing things maybe thats what you are looking for
So my question is what is the appropriate HTTP method that could be used in this scenario which is acceptable in the RESTful design standpoint.
The world wide web is about as RESTful an example as you are going to find, and HTML forms only support GET (which should not have a request body) and POST. So POST must be fine (and it is).
More generally, POST can be used for anything; the other methods should be used when they are a better semantic fit. For example, you can use POST to make a resource unavailable, but DELETE is more explicit, and generic components can do sensible things because they recognize the semantics. PUT is a better choice than POST when what you are intending is to provide the server with a new representation of a resource, and so on.
I am not able to understand why the payload of the HTTP GET is forbidden
Payload of the HTTP GET is forbidden because the standard says "don't do that".
I believe it is written that way to simplify the rules for caching the response. As written, cache implementations only have to worry about header data (including information on the start-line).
But it could be as simple as the fact that the older versions of the standard didn't require that generic components do anything specific with the message-body of a GET request, and therefore modern specifications say "don't do that" in order to maintain backward compatibility. (One of the important constraints in designing long-lived systems is that you don't break older implementations.)
I just want to know the high level steps of the process. Here's my thought on the process:
Assumption: the API returns JSON format
Check the API document to see the structure of the returned JSON
Create a corresponding Java class (ex: Employee)
Make Http call to the endpoint to get the JSON response
Using some JSON library (such as GSON, Jackson) to unmarshall the JSON string to Employee object.
Manipulate the Employee object
However, what if the API returned JSON is changed? it's really tedious task to exam the JSON string every now and then to adjust the corresponding Java class.
Can anyone help me out with this understanding. Thanks
You describe how to consume a json over http API, which is fine since most of the APIs out there are just that. If you are interested in consuming Restful HTTP resources however, one way would be:
Check the API documentation, aka. the media-types that your client will need to support in order to communicate with its resources. Some RESTafarians argue that all media-types should be standardized, so all clients could potentially support them, but I think that goes a bit far.
Watch out for link representations, and processing logic. media-types do not only describe the format of the data, but also how to process them. How to display it if its an image, how to run code that might be part of the message, how to layout onto the screen, how to use embedded controls like forms, etc.
Create corresponding Java classes. If the resources "only" describe data (which they usually do in API context), then simple Java classes will do, otherwise more might be needed. For example: can the representation contain JavaScript to run on the client? You need to embed a JavaScript engine, and prepare your class to do just that.
Make call to a bookmarked URI if you have it. There should be no hardcoded SOAP-like "endpoint" you call. You start with bookmarks and work your way to the state your client need to be in.
Usually your first call goes to the "start" resource. This is the only bookmark you have in the beginning. You specify the media-types you support for this resource in the Accept header.
You then check whether the returned Content-Type matches one of your accepted media-types (remember, the server is free to ignore your preferences), and then you process the returned representation according to its rules.
For example you want to get all the accounts for customer 123456 for which you don't yet have a bookmark to. You might first GET the start resource for account management. The processing logic there might describe a link to go to for account listings. You follow the link. The representation there might give you a "form" in which you have to fill out the customer number and POST. Finally, you get your representation of the account list. You may at this point bookmark the page, so you don't have to go through the whole chain the next time.
Process representation. This might involve displaying, running, or just handing over the data to some other class.
Sorry for the long post, slow day at work :) Just for completeness, some other points the client needs to know about: caching, handling bookmarks (reacting to 3xx codes), following links in representations.
Versioning is another topic you mention. This is a whole discussion onto itself, but in short: some people (myself included) advocate versioning the media-type. Non-backwards compatible changes simply change the media type's name (for example from application/vnd.company.customer-v1+json, to application/vnd.company.customer-v2+json), and then everything (bookmarks for example) continues to work because of content negotiation.
There are many ways to consume RESTful APIs.
Typically, you need to know what version of the API you are going to use. When the API changes (i.e. a different version is exposed) you need to decide if the new functionality is worth migrating your application(s) to the latest and greatest or not...
In my experience, migrating to a new API always requires some effort and it really depends on the value of doing so (vs. not doing it) and/or whether the old API is going to be deprecated and/or not supported by the publisher.
It is more of a design and architecture question. I am developing a new UI layer for an old system. This system accepts request in particular xml format. Currently request from the new UI layer goes to a data massaging class via controller.
This Translator/Massaging class converts UI request xml to desired request format. It adds few deprecated elements and constants to the XML it received from UI layer.
Request XML from UI is partially similar to the actual back end. But it has to go to the Translator/Massaging class to be converted into actual request.My question does UI layer need to worry about if it's request XML is partially similar to the actual request? Can UI layer just send the data in JSON format to the Translator/Massaging and translator class will convert it into the actual request xml?
My question does UI layer need to worry about if it's request XML is partially similar to the actual request?
No. As you suggested in your next question, the messaging class can convert the GUI data into an actual XML request.
Can the UI layer just send the data in JSON format to the messaging class and messaging class will convert it into the actual request XML?
It could. However, your GUI should have a data model. The GUI would interact with the data model. The data model would interact with the messaging class. There's no need for another data format, unless there's some requirement you're not telling us.
My question does UI layer need to worry about if it's request XML is partially similar to the actual request? Can UI layer just send the data in JSON format to the massaging class and massaging class will convert it into the actual request xml?
Clearly it could do that. But that would mean that the "massaging" class has more work to do.
To my mind, you are probably asking the wrong question here. If I was in your shoes, I'd be asking myself why I can't use the request format for the "old" system directly, or why I can't change the "old" system to accept requests in the "new" format directly.
Or to put it another, ask yourself what is the purpose of implementing a new format, and all of the extra coding and the performance hit of the "massaging".
Unless there is something else going on that you haven't told us, this all sounds a bit unnecessary to me.
Think services! Any functionality the server offers and is used by the client should be abstracted by a service interface, so that code using this service never has to worry about its implementation or any protocols involved. You can then have the actual implementation on the server, and a remote facade implementation for the client, which forwards the request to the server and also handles the responses:
interface SomeService {
public SomeResult doSomething(SomeArguments) throws SomeException;
}
class SomeServiceServerImpl implements SomeService {
// server-side implementation
}
class SomeServiceClientFacade implements SomeService {
// client-side facade, forwards the request, for example to a web service
}
The facade can then convert the arguments to XML, call a web service, parse the XML response and convert it back to a result object or exception.
If you use a standardized RPC (Remote Procedure Call) protocol (such as SOAP or JSON-RPC), the most elegant way to handle this would be to use a Proxy with an InvocationHandler which does the request marshalling and response unmarshalling in a generic way, allowing you to cheaply create remote service proxies.
A full REST api like with Java's jax-rs contains definitions for defining a path for a resource, uses the full GET, POST, PUT requests.
But typically when I encounter a REST API, it is typically a standard HTTP GET request and the response is a JSON output. It seems like the meat of a real-world REST request is using JSON output but the true definition of REST allows for XML, JSON or other output types.
For example, the twitter API has "JSON" output, they use a GET request and here are some of the URL's:
https://dev.twitter.com/docs/api/1.1/get/search/tweets
And you can still use the "GET" parameters to modify the request. It seems like the twitter 'search/tweets' function is just a simple http request with a well defined URI path that happens to return a JSON response. Is that really REST?
What is a REST api to you?
On Jax-rs
http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services
(Sorry if this is slightly subjective or anecdotal but I believe developers were wondering about this)
REST (Representational State Transfer) is a vague architectural design pattern which was first written about in a paper by Roy Fieldings (aka the guy who created HTTP).
Most of the time (99% of the time) when somebody wants a REST API they mean they want a web API where they send a Request containing an HTTP verb and a URL which describes the location of a Resource that will be acted upon by the HTTP verb. The web server then performs the requested verb on the Resource and sends back a Response back to the user. The Response will usually (depending on the HTTP verb used) contain a Representation of the resulting Resource. Resources can be represented as HTML, JSON, XML or a number of other different mime types.
Which representation used in the response doesn't really indicate whether an API is RESTful or not; it's how well the interface's URLs are structured and how the web server's behaviors are defined using the HTTP Verbs. A properly compliant REST API should use a GET verb to only read a resource, a POST verb to modify a resource, a PUT to add/replace a resource, and a DELETE to remove a resource. A more formal definition of the expected verb behaviors are listed in the HTTP Specification.
REST is (in a nutshell) a paradigm that resources should be accessible through a URI and that HTTP-like verbs can be used to manipulate them (that is to say, HTTP was designed with REST principles in mind). This is, say, in contrast to having one URI for your app and POSTing a data payload to tell the server what you want to achieve.
With a rough analogy, a filesystem is usually RESTful. Different resources live at different addresses (directories) that are easy to access and write to, despite not being necessarily stored on disk in a fashion that reflects the path. Alternatively, most databases are not RESTful - you connect to the database and access the data through a declarative API, rather than finding the data by a location.
As far as what the resource is - HTML, JSON, a video of a waterskiing squirrel - that is a different level of abstraction than adhering to RESTful principles.
REST is a pretty "loose" standard, but JSON is a reasonable format to standardize around. My only major concern with JSON overall is that it doesn't have a method for explicitly defining its character encoding the way XML does. As for the verbs, sticking to meaningful usages of the verbs is nice, but they don't necessarily map one for one in every situation, so as usual, use common sense :)
It can be JSON, it can be XML. JSON is not exactly industry "standard," but many developers like it (including me) because it's lightweight and easy.
That's pretty much it. REST is designed to be simple. The gist of it is that each url corresponds to a unique resource. The format of the resource is commonly json, but can be anything, and is typically determined by the "extension" or "format" part of the url. For example, "/posts/1.json" and "/posts/1.xml" are just two different representations of the same logical resource, formatted in json and xml, respectively. Another common trait of a RESTful interface is the use of HTTP verbs such as GET, PUT, and POST for retrieving, modifying and creating new resources. That's pretty much all there is to it.