I am trying to implement deprecation header for api responses in my application. The problem is that recently our codebase has gone through major refactoring and restructuring with lots of apis being deprecated. all of these api endpoints are annotated with #Deprecated. is there anyway i can use this annotation to change the response without having to make code changes at each and every endpoint location?
I have tried to change response in the code at each location and this would be tedious, expecting a smarter way to go about this.
Note- My application is in JAVA and uses spring-boot framework.
Related
I am using org.apache.http.entity.mime.MultipartEntityBuilder for sending the multipart form data using apache HttpClient in a SpringBoot Application.
Recently, I saw a usecase , where one of the request was giving response as
415 Unsupported Media Type
While trying to debug the issue, I changed the MultipartEntityBuilder object's HttpMultipartMode from BrowserCompatible to Strict . And it started giving the expected response 200.
I tried to search a lot but still not able to completely understand what impact does changing the HttpMultipartMode makes.
Can someone please help me to understand this?
You can check the source code for more information:
https://www.javadoc.io/doc/org.apache.httpcomponents/httpmime/4.5.7/org/apache/http/entity/mime/HttpMultipartMode.html
Strict seems to follow the RFC standards, BrowerCompatible not
When I have issues like these I usually make sure to test my request outside of Spring (i.e. Postman or similar) to understand the differences headers make (usually different headers will be the problem in some way)
Curious to know other side code, While implementing API (rest service), what changes make this difference. To make API strict mode what particular changes I have to make in code.
I need to consume REST API. There are many REST clients for Java. Are there any areas of concerns before proceeding this?
You can use HttpClient for that. However, if you are working on a spring enabled project, I would recommend using RestTemplate.
Rest template provides an abstraction over HTTP client as a result of which you will not have to deal with serialization/deserialition, error handling, SSL configuration in every part of code where you make a REST call. You will just need to configure those with REST template configuration once and not worry about it. This makes your code clean and easily maintainable in case you wish to change the way your application talks to the back-end restful application in future.
I've 2 questions about Java Rest APIs
1'st:
I would like to create a Rest API with Java Servlets for using in the mobile applications(IOS and Android)
and before doing that I would like to clarify the rest api content. However as much as I search through google all I found was automatic API creators from your Java code. But what I want is different first I want to document our Json Rest API so mobile and server developers can start to work independently.
Do you know any tool for that?
2'nd:
What I want to achive in our java server application is simple. Get simple json requests from mobile clients and do some database query and respond back with simple json objects.
For achiving this do I need to use any additional Rest API framework such as spring mvc (or something else) or just using Java Servlets and parse the request in doPost method and respond it there
Which one do you suggest?
Thanks
Restlet Studio (http://restlet.com/technical-resources/restlet-studio) or APISpark (http://restlet.com/products/apispark/) can bring you what you expect.
Restlet Studio allows you to define / design you API with a Web IDE: resources and their methods, representations (exchanged data structures). You can then have access to corresponding Swagger content and generate online client SDKs and even server skeletons for your API (this is internally based on Swagger Codegen)...
To implement your RESTful applications, Restlet can help you. It's a Java REST framework to access and / or implement RESTful applications. Restlet can be used within a servlet container with its servlet extension (see this link https://github.com/restlet/restlet-tutorial/blob/master/modules/org.restlet.tutorial.markdown/02_Server_Side/04_Server_Deployment/02_Servlet_Deployment.md).
Hope it helps you.
Thierry
I aggree with Stephan comment.
With Spring Boot and Spring Data Rest, the only code you will need to write is the mapping between your DB and your DAO Entities.
To document your API before writing it, you can use in fact any regular tools.
REST APIs don't have anything specific compared to others APIs to be documented.
Much of the documentation of APIs I've written were using Ms-Word...
Swagger provide a Json syntax to document a REST API, but it is mainly useful when used with Swagger-Ui, which allow to request the deployed server dynamically. You can use Swagger for your documentation, but as there will be no already existing server, I'm not sure it is worth the cost of learning its syntax. The main benefits is to give you constraints (like predefined fields) to follow.
By the way, I think that writing a REST Api Mapping or just document it takes the same amount of time, so I'm not sure it is really worth making all the documentation in a stand-alone way.
I'm using the Play framework to build a web app which integrates with Salesforce via their REST API. In order to send an upsert command to their interface, it seems as if I must use the PATCH method instead of a POST method request. Is it possible to use Play's WSRequest object and change the method type to PATCH instead of POST? If not, how can I use a request object and send a PATCH request instead?
For learning purposes, what is the PATCH method and why does Salesforce enforce use of it instead of a POST method?
I'm not sure about what is available in Play, but from the REST API documentation, here is a workaround if your library doesn't support PATCH:
If you use an HTTP library that doesn't allow overriding or setting an
arbitrary HTTP method name, you can send a POST request and provide an
override to the HTTP method via the query string parameter
_HttpMethod.
For example, to update an Account, this will work with an actual POST request:
.../services/data/v23.0/sobjects/Account/0016000000eEhmxAAC?_HttpMethod=PATCH
As for the reasoning behind using PATCH, it is because PATCH is for partial updates to a resource. That is, you only have to send the fields you are updating. If you were required to send all the fields for a record in updates, PUT would probably be a better choice. POST is generally only for new inserts. Here is an explanation with examples:
http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch
Play doesn't include a PATCH method in his WS library.
You could manually extend some classes from the framework in your app to add this method (mainly these two), but I believe that the alternative provided by #ryanbrainard is a beter approach: use the _HttpMethod parameter in a POST to flag is as PATCH.
I'm getting ready to dive into testing of a RESTful service. The majority of our systems are built in Java and Eclipse, so I'm hoping to stay there.
I've already found rest-client (http://code.google.com/p/rest-client/) for doing manual and exploratory testing, but is there a stack of java classes that may make my life easier? I'm using testNG for the test platform, but would love helper libraries that can save me time.
I've found http4e (http://www.ywebb.com/) but I'd really like something FOSS.
You can use REST Assured which makes it very easy to test and validate REST services in Java from JUnit or TestNG. E.g. let's say that a GET request to a service called "/lotto" returns the following JSON
{
"lotto":{
"lottoId":5,
"winning-numbers":[2,45,34,23,7,5,3],
"winners":[{
"winnerId":23,
"numbers":[2,45,34,23,3,5]
},{
"winnerId":54,
"numbers":[52,3,12,11,18,22]
}]
}
}
then you can make the request and validate the response (in this case that lotto id equal to 5) with REST Assured like this:
expect().body("lotto.lottoId", equalTo(5)).when().get("/lotto");
Would JMeter be an option? It has HTTP Request samplers that support all of the HTTP methods and assertions to validate the response.
Another alternative might be something like soapUI which has an API that could be integrated with your test cases, though I haven't tried it.
CXF apparently has support for REST. I haven't tried the REST support yet myself, but I think CXF is a superb, flexible, standards-based webservice implementation.
Another informal option to test your REST services is by using the Firefox RESTClient Add-on.
Postman REST Client for Google Chrome is another option.
Apparently rest-client has a library built in. I'm using that with testNG and XStream and it seems to be exactly what the doctor ordered.
I was working today around the unit testing of a rest service, I needed to test the deployed server in order to check some concurrency requeriments, so I needed to test the deployes rest service.
At first I tried the solution sugested by Johan, and started with REST Assured with some succes, but look for more documentation, I found this:
http://uttesh.blogspot.com/2012/09/spring-rest-web-service-test.html
its based on a spring library, so if you are using spring, you'll keep using the stuff from the same vendor, which is always nice.
Also I found the libs from spring easier to understand than REST Assured, but it's just me ;)