Changing the JSON format for spring-data-rest - spring-data-rest

Currently spring-data-rest is returning JSON in HAL format in a spring-boot project of mine. I am using an ember.js frontend and want to use jsonapi (http://jsonapi.org/) specification.
How might I register a new JSON formatting strategy given I will need to write the formatter myself as one does not exists yet?

This is how you can customize the HATEOAS that Spring Data REST produces:
https://docs.spring.io/spring-data/rest/docs/current/reference/html/#customizing-sdr.customizing-json-output
If you need to completely replace the JSON representation with your own, then you can write and register your own org.springframework.core.convert.converter
Or you write your custom REST endpoints in a plain old #RepositoryRestController and implement your own REST endpoints. (<= I suggest try this)

Related

How to display a json response mapped pojo in sightly

I have a sling servlet that invokes a 3rd party api and fetches a json response. I have mapped the json response to a pojo class using Jackson. I now have to display this dynamically fetched and mapped response in sightly. How do i do that? I am stuck after the response mapping
With the new version of Sling Models, you can directly expose a model as a Servlet by specifying a resource type and the selector to use in your model annotations. When the Model is loaded into Apache Sling, it automatically registers a Servlet corresponding to the model, allowing you to with nearly zero additional code, create a Servlet to access a JSON representation of the model. That’s super cool!
The above life makes your Life Easier!!
You can have all your objects in Sling Model. Since the sling model acts as a servlet You can make the AJAX call and get a real-time response.
Please refer to this document.
https://blogs.perficient.com/2018/07/26/no-servlets-required-exporting-data-with-sling-models/
The correct path is:
HTL/Sightly -> Sling Model -> OSGi Service -> External API
So you have to extract the code that fetches the data into an OSGi service.
But please secure your code that calls the external API. As example if the External API is not responding or is extremely slow, it could consume all available threads of AEM. Then AEM could be completely unusable. To secure it, you could use as Example a Semaphore.
Assuming the JSON returned is arbitrary, the best thing to do is simply display it as a string. To do that, instead of mapping the JSON response to a POJO I would recommend adapting a Sling model to the response.
Then, you can set that Sling model to be the model in your sightly code, using data-sly-use.model, and in the Sling model constructor you can set the response value to an attribute of the sling model.
Then all you'd need to do is put that attribute in a ${} in the sightly html.
If the format/structure of the JSON isn't completely unknown, you could use the POJO in the sightly. Create some conditionals to test what attributes the POJO has, so you can put them into the sightly code.

open API spec to Odata raml conversion in mule4

I need to expose the rest API as OData service in Mulesoft. I have the below questions.
Is there an easy way/tool to convert openAPI spec to odata(RAML) to use it in APIKit router in mule4.
How we can define complex datatypes in odata.raml file.
You can use open api APIs directly with the last version of APKit and Studio without any conversions:
https://docs.mulesoft.com/release-notes/platform/oas3
On the other hand I'm not sure if you are trying to use OData. That's a different standard. See the instructions for the OData plugin: https://docs.mulesoft.com/apikit/4.x/creating-an-odata-api-with-apikit
You cant define complex data types in odata.raml, but you can now use apikit for odata 4

Spring Auto REST Docs + Spring Data REST? HATEOAS?

I really like the idea of using Javadoc comments for auto-generating REST Docs!
Huge parts of our REST API are automatically generated by Spring Data REST (by adding #RepositoryRestResource to Repositories). It would be great if REST Docs could also be generated for these - that would be a very high degree of automatition.
But unfortunately most "auto-"snippets are "empty" (e.g. auto-response-fields.adoc only contains a list of links[]-Attributes). I guess the reason could be that the REST Controllers are probably created dynamically by Spring Data REST. Currently I do not see how to re-use the Javadoc comments for them.
Is there any way to auto-generate REST Docs for such REST APIs that are provided by Spring Data REST?
It would even be helpful to manually tell Spring Auto REST Docs which classes are used in requests and responses instead of letting it discover it statically - is that possible?
And we also add HATEOAS "_links" to most response Resources (by providing ResourceProcessors as Beans). These links contain "title"s which are used by Spring REST Docs - if we list all of them with HypermediaDocumentation.linkWithRel(...). This is a bit redundant, and it would be nice if all the _links with "title"s could be processed automatically. (But this can be done by listing all of them in some extra code, so it is not as bad as with Spring Data REST.)
If necessary, I could also create an example project for what I am talking about.
Answer to the question whether one can manually tell Spring Auto REST Docs which classes to use for the documentation:
Spring Auto REST Docs allows to specify the request and response classes to use for the documentation. This can be done with requestBodyAsType and responseBodyAsType. In a test it looks like this:
.andDo(document("folderName",
requestFields().requestBodyAsType(Command.class),
responseFields().responseBodyAsType(CommandResult.class)));
This is from a test in the example project.

Implementing REST hypermedia using WCF

I have a WCF-based REST service and I'm planning to add hypermedia support to it. Currently I'm relying on WCF to build the service response by serializing my data contracts. With hypermedia in the picture now, I need a way to instruct WCF to insert hypermedia links in the XML response that it builds. My question is, how do I do that?
One way could be that I modify my data contracts to include the said links as data members. Then WCF can automatically serialize them. But is that the best practice? Or is it better to intercept WCF's serialization process and add these links at that time? Or is there any other more suitable alternative?
You need to construct the hypermedia yourself. If you choose Atom there are some helpers. Basically you create a SyndicationFeed and add SyndicationItem items to it and use an Atom10FeedFormatter to turn the whole feed into an Atom document.

Is it possible to implement a redirector / reverse proxy using RequestInterceptor from WCF REST Starter kit

I am attempting to implement a reverse proxy using the RequestInterceptor from WCF REST starter kit. I am able to set the basic header properties and configure the calls. I am getting stuck with the following aspects:
Returning an appropriate response - my webservice can return text+xml, image or json. I am not able to send the appropriate response type. The Message.CreateMessage overloads are all SOAP aligned i.e. they accept only Xml constructs, so I am not able to send either JSON or image streams. I need to convert them into XElements - I am definitely doing something wrong here.
I also want the reverse proxy to be functioning well in the presence of cookies, gzip/deflate and SSL.
Based on the above requirements, do you think it makes sense to do this using REST starter kit? The Requestinterceptor was fairly easy to plug into, however the rest of the code is driving me nuts.
There is a mapping between both JSON and arbitrary binary content to XML which is used in messages for WCF (see some examples at http://blogs.msdn.com/b/carlosfigueira/archive/2011/04/19/wcf-extensibility-message-inspectors.aspx), so you can use Message.CreateMessage to create non-XML messages as well.
Having said that, it's really not intuitive to do that in WCF as of now. The new libraries in the WCF Web API - http://wcf.codeplex.com - provide a very nice way of intercepting / redirecting / bypassing the WCF pipeline especifically for HTTP messages. Also, it support multiple formats in a native way (i.e., without need to do some mapping to XML).