Read the documents but couldn't find support for using jersey filters (ContainerRequestFilters, Filters etc).
Can someone please some examples of using Jersey filters in lagom?
Lagom isn't based on Jersey, so you can't use Jersey filters directly.
Lagom provides its own APIs for transforming requests and responses.
See Header Filters and Service call composition for examples.
Related
Before embarking on API development, looking to choose the right foundation.
So...OData permits queryability over models. Great!
...but REST apis can be decorated with the [Queryable] ...
So... what is the remaining advantage of OData over such Queryable APIs?
Maybe the following are true?
OData routing relies primarily on convention based routing, so not sure one can craft if ever needed to (e.g.: to avoid legacy routes one has to implement?)
Suspect one cannot query REST APIs based on child entities?
Anything else that would come into play?
Thank you!
OData is a specific and standardized implementation of REST. If you make your standard API endpoint's queryable then those specific endpoints will follow most of the OData v4 response conventions but it is up to you to document this for the consumers.
When you choose to start from OData, you are choosing to implement the OData conventional standards for all of the controllers and Entities that you choose to include in the OData Entity Model. This in turn will generate the $metadata document that describes the model and the supported functions and actions.
You can add custom types, functions and actions to an OData controller if you follow the conventions correctly. You can also directly host standard API controller endpoints if you want to, but unless you register them with the OData model, they will not be included in the $metadata document.
You could choose to replicate or implement the entire OData specification in your API from first principals if you want to, including producing your own $metadata document... But if you were going to go to all that trouble then it would have been far easier to just use the ODataController and implement OData properly.
Making the decision to use OData over standard Web API is usually driven by your chosen documentation method and if you can accept the general OData query conventions and if the consumers of the API can understand OData. OData standards are clearly defined so that you don't have to worry as much about educating consumers on how to use your API and can focus more on the implementation itself.
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
The new WSO2 API MicroGateway 3.0 states as new feature Support for composing multiple microservices.I cannot find an example of how to do that.
We are trying a use case with just this type of processing:
An API that queries a back-end database using OData and if not found queries another (non OData) API.
In both cases the result must be transformed (reformatted).
Idea of composing microservices, is to expose set of microservices as a single API using microgateway. Basically you can define define set of REST resources and then point them to different microservices. For ex:
/list . -> micro service1
/add -> micro service2.
You can define per resource back ends using swagger (open API) extensions as below
https://github.com/wso2/product-microgateway/blob/master/samples/per_resource_endpoint.yaml
As of now microgateway does not have out of the box capability to call subsequent endpoints based on the response from the previous endpoint.
But you can transform the response using the response interceptors as explained below link
https://docs.wso2.com/display/MG300/Adding+Interceptors
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.
I have an application that will be consuming several REST APIs by a number of third parties and I am tossing up between using HttpClient and ServiceStack.Client to consume them.
I'd love to stay unified and use ServiceStack.Client, but I'm not sure if it's targeted more to support the patterns & practices of a ServiceStack REST API or whether it is flexible enough to be used to consume any arbitrary HTTP REST API.
Specifically, the APIs I am consuming have their own custom authentication methods (not basic or digest etc) and require the client to accept cookies. Is ServiceStack.Client appropriate to use in these scenarios?
Following on from what #mythz said, I ended up using the ServiceStack HTTP Utils library.
To handle cookies and custom authentication requirements, I hooked the 'requestFilter' parameter that is available in most of the extension methods, to manipulate the post's header prior to it being sent. It's just a simple Action.
It's covered my needs quite well and been quite elegant.