I am trying to learn REST web services. But it seems to use annotations every where. Is there any implementation of Rest framework without using annotations.I have no idea about annotations.
Thanks
REST does not use annotations. REST is just a spec of good wishes. It does not dictate anything. You are right: the most of existing implementations user annotations. And IMHO it is good.
But if you do not want to use them implement REST yourself. It is easy. For POST create servlet that impelments doPost(). Extract data from URL. Call underlying layer with these parameters. For GET method implement doGet() that does pretty the same.
This is the idea of REST. Nothing more. What frameworks do is just the parsing of the arguments and marshalling/unmarshalling of data. But if you data is marshalled as XML or JSON (or any other format) you can implement all this yourself very quickly.
Happy RESTing!
Related
I do transform my XML file into java objects, after some researche i find many API : JAXB, JAXB2, Casto, Xtream, Simpl, XMLBeans...
I would like to know the best one to use for this manner in the context of spring boot, micro-services. reliable, fast, simple. can you give an some exemple.
thank to all.
According to my experience with Xsteam is the best choice not only for XML but for JSON with or without annotations.
Other API is highly dependented on Annotations.
So if you have dynamic class object then go for Xstream.
I am implementing a REST API using javax.ws.rs. An implementation goal is to be as secure as possible, so every input should be validated.
For input validation, I am implementing a public class ValidatingHttpRequest that implements HttpServletRequest.
I could identify 11 methods which are even called, all the others now throw UnsupportedOperationException. However some of those methods handle things apparently used by the REST framework. For example my code does not care about headers, but getHeaders gets called. With a lot of reverse engineering I would be able to figure out what headers are used and should be validated, and of course I could do the validation. Possibly with introducing nonoptimal behaviours and maybe some bugs. And there are some similar aspects of the HTTP request.
But no one did this before, possibly someone who actually knows how the REST framework works? Or is it unnecessary, as the framework itself cannot be fooled?
So I am looking for a fully validating HttpServletRequest implementation, or a reasoning why it is unnecessary in this case. Of course I will validate the request body and parameters using the implementation.
I am implementing a REST API using javax.ws.rs. [...] For input validation, I am implementing a public class ValidatingHttpRequest that implements HttpServletRequest.
You are missing the whole point of JAX-RS. In JAX-RS, you deal with annotated resource classes and methods, so you don't need to write "low level" Servlets.
I am looking for a fully validating HttpServletRequest implementation, or a reasoning why it is unnecessary in this case.
You definitely don't want (and don't need) to write a Servlet for validation purposes.
JAX-RS implementations such as Jersey, RESTEasy and Apache CXF support Bean Validation, an annotation-based API to validate Java Beans. You can validate pretty much everything you need, including request headers, parameters and entities.
Check the chapter 7 of the JAX-RS specification, it describes how validation works. However, to integrate Bean Validation with JAX-RS implementations, you want to see the vendor-specific documentantion:
Bean Validation with Jersey
Bean Validation with RESTEasy
Bean Validation with Apache CXF
I'm returning to backend development after a few years focusing on iOS. I've chosen Spring Boot with Kotlin.
I would like to have a domain-centric, general, reusable model objects.
For service invocations I would like to return use-cases specific responses where the payload in/out is just the information for that particular scenario. (We can call this "contract-first" or "don't spill your guts")
In the past I might've implemented a service by mapping the information from reusable model objects onto a serializable value object using a framework like Dozer.
Alternatively, I was thinking of registering a custom serializer for a given endpoint, as eg Django Rest Framework does. (Not sure how this would work given jackson serializes by annotations).
Questions:
Is there an easy way to use custom serializers with jackson to do what I want?
Or is it better to continue using the value-object approach I used years ago?
Depending on your use case, using dedicated DTOs could be a good idea. Just so you know, you can get more flexibility from Jackson without implementing custom serializers for each scenario - Jackson Json Views are now supported in Spring MVC and quite useful.
For a web application, I need to return a model to a view.
For a mobile application or API, I want to return xml or json.
Is it possible to do all of these using a single controller method, or do I have to duplicate this and create seperate API controller's etc?
With Spring MVC 3.x you can do this with just the one controller method. The trick is to wire up the appropriate ContentNegotiatingViewResolver in your Spring config. You can configure it to return the desired content type based on file extension and/or requested mime type.
It works best for methods that only add a single model attribute to the Model, otherwise the JSON/XML starts to get a bit ugly.
I often find its simpler/nicer to implement separate controller methods for my web service requests, as you can better control the format of the JSON/XML and the code is easier to maintain in the long term.
EDIT: Just to qualify my comment above, I find that complex JSP pages where there might be up to 5-10 model attributes added to the page, that the resulting JSON tends to be quite messy and you usually find you only really want 1-2 of those in the JSON. OTOH, simple pages with 1-2 models added work quite well.
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.