im trying to implement an spring android client for a Hypermedia API with responses in HAL format. The Spring HATEOAS - Reference Documentation described the implementation with client side service traversal inspired by the Traverson JavaScript library.
I do this this way:
Traverson traverson = null;
try {
traverson = new Traverson(new URI(getString(R.string.api_test_uri)), MediaTypes.HAL_JSON);
} catch (URISyntaxException e) {
e.printStackTrace();
}
String name = traverson.follow("movies", "movie", "actor").
withTemplateParameters(parameters).
toObject("$.name");
But i'm getting following error while creating a new Traverson object:
java.lang.NoClassDefFoundError: org.springframework.hateoas.hal.HalLinkDiscoverer
Do somebody know how to fix it?
Is there probably other/better ways to support HAL responses in android?
As best I can tell, Spring's Traverson implementation is not usable in Android, because it is part of the Spring HATEOAS module, which depends on spring-core, which ultimately depends on the JDK's implementation of StAX. Android doesn't have a StAX implementation, and because it's in a javax.* package, the Android runtime won't allow you to load one.
In a blog post, Josh Long describes the process of adapting Spring Social and Spring Security to work on Android; essentially, you have to strip out most of their dependencies and selectively re-add only the ones you need. However, you can't work around packages like JAXB or STaX whose Android implementations are incompatible or missing, so you have to rewrite the code that depends on them to use something else instead.
A request has been posted against the spring-hateoas project to support Android, but it was closed (two days ago as I write this) with the comment "we can't commit resources to such a platform specific feature at this time". (On the other hand, someone else seems to be having success with the method described above, so maybe it's worth pursuing?)
Mike Kelly, in his documentation on the HAL standard, supplies a list of libraries that support HAL. I'm currently putting together a solution based on HalBuilder, which looks promising so far.
tl;dr: Spring's Traverson won't work without a lot of effort on your part. You may be better off building your own. Use your favorite HTTP library along with a HAL library, and you're most of the way there.
Related
For the V3 Version of the API I found quite a few questions here on Stackoverflow.
There are also libraries available at https://developer.github.com/v3/libraries/.
I'd rather use the V4 api because I intend to do an integration for the simplegraph open source project see https://github.com/BITPlan/com.bitplan.simplegraph/issues/5
For the V4 API i found the following links so far:
https://developer.github.com/v4/explorer/
https://developer.github.com/v4/guides/forming-calls/#the-graphql-endpoint
https://api.github.com/graphql
https://stackoverflow.com/questions/tagged/graphql-java
https://github.com/graphcool/get-graphql-schema
https://developer.github.com/v4/guides/forming-calls/#example-query
https://www.howtographql.com/graphql-java/1-getting-started/
http://graphql-java.readthedocs.io/en/v7/schema.html
https://github.com/graphql/graphql-js/issues/657
It looks as a starting point a Schema definition like this one:
https://github.com/graphql-java/graphql-java/blob/master/src/test/groovy/graphql/StarWarsSchema.java
would be helpful.
Where can I get souch a graphql-java useable schema definition of the github V4 api?
Would it be possible to somehow create this from the Json response of the
query {
__schema {
types {
name
kind
description
fields {
name
}
}
}
}
query?
At http://wiki.bitplan.com/index.php/GitHub-GraphQL I am documenting my next steps.
You're looking at the wrong tool then. graphql-java is an implementation of the GraphQL spec. It's used for developing GraphQL servers in Java.
What you're looking for is a client. There's currently only 2 available, neither great but likely usable.
Apollo Android - Don't let the name throw you off, it's perfectly usable from normal Java
Shopify's Java gen - Generates a Java client from the given schema, similar to wsdl2java. Requires Ruby.
Here: https://github.com/octokit/graphql-schema/blob/master/schema.graphql is the GitHub v4 API schema. You can use this schema with graphql-java library.
I'm trying to figure out the best way to have my API documentation be the source of truth and use it to validate the actual Java REST code ideally through integration testing or something of that sort. We're using the contract first or consumer contract type of approach, so we don't want the documentation to be generated from annotated code necessarily and updating every time a developer makes a change.
One thought has been to use Swagger, but I'm not sure how best to make it be used for validating the API. Ideally, it'd be good to have the validation occur in the build or integration testing process to see if the real response (and request if possible) match what's expected. I know there are a lot of uses and tools for Swagger and just trying to wrap my head around it. Or if there is a better alternative to work with Java code.
Recently, we (swagger-codegen community) start adding automatic test case generation to API clients (C#, PHP, Ruby). We've not added that to Java yet. Here are some example test cases generated by Swagger-Codegen for C#:
https://github.com/swagger-api/swagger-codegen/tree/master/samples/client/petstore/csharp/SwaggerClient/src/IO.Swagger.Test
It's still very preliminary and we would like to hear feedback from you to see if that's what you're looking for.
I think you should try swagger-request-validator:
https://bitbucket.org/atlassian/swagger-request-validator
Here are some examples how to use it:
https://bitbucket.org/atlassian/swagger-request-validator/src/master/swagger-request-validator-examples/
Another alternative is assertj-swagger:
https://github.com/RobWin/assertj-swagger
You may want to look at Spring Cloud Contract. It offers you a DSL, where you can describe the scenarios (more or less what is the response I get for a given request) and it seems to fit well to what you described as a requirement...
If you're using the Spring Framework, I'd highly recommend checking out Spring RestDocs which allow you to generate
I've got a problem with resources linking in Dropwizard. With JAX-RS 2.0 we've got magical javax.ws.rs.core.Link class which with it's builder can do almost all the work for you. Unfortunately Dropwizard 0.7.1 doesn't depend on the new 2.0 API, but on the old javax.ws.rs:jsr311-api API, which can't handle linking. Or can it? This is the problem I want to solve with Dropwizard. I probably have two ways to do it and I don't know if any of them is valid:
Option 1: I add JAX-RS 2.0 dependency to my project. Voila! I've got Link. But the problem is, that it doesn't work well with old implementations from Jersey - I got AbstractMethodException from UriBuilder, which apparently changed from version 1 to 2. So the answer is to supply new implementations. Can I do it? If yes, than how can I do it? Will new implementations work with dropwizard well?
Option 2: I can just add some other resource linking to dropwizard. Is there some other linking standard/library? I can't use jersey-declarative-linking because it mixes representations with the resources (the linking takes place in representations), and I want my representations not to know a thing about resources layer. So is there another linking standard for Dropwizard, Jersey and JAX-RS 1?
I've finally found an answer to my question.
Option 2 was a dead end. There was no other jax-rs-2-like linking library to either dropwizard or jersey itself.
Option one also was hard to do, but fortunatelly yesterday dropwizard released version 0.8.0-rc1 of their framework, which depends on jersey 2, which is the implementation of JAX-RS 2.0. So for all of you that want to have HATEOAS in dropwizard, version 0.8.0 is for you.
I have developed a REST API using Play! Framework 1.2.4, and I have a strong liking for the framework. The simplicity and the rapid development cycle helped me achieve this in a fraction of the time I would have taken had I gone the traditional Java EE route.
Now that I am exploring using Play! 2.0.3 for my next project. I see that while the framework has been enhanced and makes it even easier to develop web-apps, the same cannot be said about REST API's. My app will not have any HTML whatsoever - I will just respond with XML or JSON or whatever data exchange format I decide to use in future.
So, the question is:
Has anyone here used Play 2.0.x for exposing non-html pure REST API's?
More Details:
Here are some of the factors I feel make it more difficult to develop pure REST API's in Play 2.0.x compared to 1.2.x. Please correct my understanding if I am wrong.
Content Negotiation is harder
In play! 1.2.4, I content negotiation was build in to the framework. There were options to define right in the routes file what content-type a request expects.
GET /friends User.listFriends(format:'xml')
Then, in the controller,
public static void getFriends(){
render();
}
This would result in the views/xml/User/listFriends.xml template being rendered automatically. To add support for JSON tomorrow, all I needed to do was to add a views/json/User/listFriends.json template.
I do not see how this can be done in play! 2.0.x
Creating non-html templates is less intuitive
After some trial and error, I figured out that one can create, for example, a listFriends.scala.xml in the views folder in play! 2.0. Then, it needs to be invoked in the controller code as follows:
return ok(views.xml.listFriends.render());
However, Eclipse doesn't like this, because Eclipse does not know about the views.xml.listFriends since it is generated only after play compilation completes. Is there anything I'm missing here?
In Play (Scala) you can do something like this:
val myXMl = obtainXML();
return Ok(myXML).as("text/xml")
I'm not sure of the syntax in Java, but it would be equivalent: instead of creating a template, you generate the XML and then you send it to the user, setting the return type to "text/xml" (or json or whatever you need it to be).
As Pere Villega explained, but with the Java syntax:
String xml = getXMLAsString();
return ok(xml).as("text/xml");
The as() method is part of the Status class.
Or, an alternative is:
String xml = getXMLAsString();
response().setContentType("text/xml")
return ok(xml);
Spring-data-rest is currently RC1 (heading for GA July 16), but the documentation is still a little sketchy. So far all the example code I find shows responses defaulting to JSON, but I need XML, and ideally either XML or JSON based on ACCEPT header. I found one source in some comments in a DZone link that indicate XML is going to be supported. But that was posted during the M2 release, before RC1. I don't see anything in the Issues under the project either.
So does anybody know how to make either RC1 (or SNAPSHOT) produce XML instead of or in addition to JSON.
I wish there was an easy answer to producing XML in Spring Data REST, but I haven't found one yet. We defaulted to using JSON because we figured that's a super easy and lightweight "protocol" for transmitting objects and will work good enough for most cases.
There are a couple of problems with XML that we haven't found reasonable answers for:
How do I represent an object in XML? Do I use the property name as the element name or do I use a standard element name and put the property name in an attribute?
Where do I identify the type of the property (whether it's complex or simple, a Long, a BigInteger or what have you)?
Do I dispense with all the custom mapping information and just use JAXB or Spring OXM?
What do I do about links? Do I use the Atom namespace link element?
If I'm using Atom already, then why not use an Atom representation for everything?
Since answering these questions will necessarily involve more community input than we've had yet since the project is so new, I was thinking we'd wait until a post-1.0 release to add XML support. Priorities could obviously change if there's enough momentum in that direction, but I just don't see it happening in the next week.
There is some machinery you can override (this is just a Spring MVC application, after all) to produce any kind of a response you want. If you use the latest snapshot and override the RepositoryRestMvcConfiguration.contentNegotiatingViewResolver() method, you can provide an entirely different representation of the DTO coming out of the exporter. This is referred to in the wiki. You'll have to check the source code of JsonView to get the necessary details on what the DTO looks like internally, but it would be relatively easy to replace JsonView with MyOwnXmlView.
NOTE: This will only work for the current version of the REST exporter. The GA version will have different machinery to render output. I'll be providing hooks for doing whatever types of output rendering one wants to do, though, so you should be able to override output rendering by setting a property on the configuration. If you create a View subclass for this version, it will likely only be a matter of changing it to an HttpMessageConverter for the GA version.
Well with latest Spring IO Platform we can achieve this and with IO Platform we
dont need to worry about version also.
Have posted how to achieve in another stack overflow link as below :
Spring Boot REST with XML Support