How to design RAMl sdk?


#1

How to develop RAML sdk?
What are the steps need to follow ?


#2

By SDK you mean client framework I suppose?


#3

yes… I have to develop java framework which will be used to develop client application…


#4

Unfortunately, we only got a Javascript template for our client generator, but you can “easily” create and add a Java template to the client generator tool.

All you need is to go to ‘https://github.com/mulesoft/raml-client-generator’ where you can find the main source for the client-generator tool and an the JavaScript template to create JavaScript clients, and this URL https://github.com/mulesoft/raml-client-generator/blob/master/IMPLEMENTATION.md for the implementation guide. It would be nice to have a template for Java as well. Are you planning on contributing it to this project?


#5

THanks for the information…


#6

I am also working on something like this in my spare time. Not to a point where I can start a Github and share it, but my goal is a bit lofty. I am hoping to use the RAML-to-java module, which will load up the RAML doc, and then use that info to pull out all the schemas (both json and xsd) and attempt to create POJOs on the XSDs and JSON Schemas (currently in Java, but also will look into Python, .NET and Ruby if it’s possible to create POJOs and use them like I can in Java). The POJOs will be the DTOs basically that both the client side and server side use. In fact, there is a separate forum post about the RAML-JAXRS project in which I didn’t realize that project actually creates POJOs from the JSON Schema (but not XSDs). I’ll be exploring that as well to see what can be leveraged. Anyway, the goal is to build a one stop shop tool that can take a RAML file, generate POJOS, JAX-RS server side code, and Java SDKs that use Jersey as well as HttpClient (so two separate versions of SDK transports) with the POJOs to make calls on the JAX-RS generated resources. Also hoping to build (or contribute to) a RAML to HTML using ReactJS + BootStrap CSS if all goes well. This will take quite some time to put together, but my end game is to have a scriptable tool of sorts that could be integrated into a build system and generate the whole shabang in one go.

In the mean time, another forum post pointed to a useful site call apimatic.io. It can now read a RAML file in and spit out SDKs in several client languages. I am not sure if there is a way to automate that step or if you must manually use their site. But take a look at it. I think the Java and Android SDKs use the HttpClient library. Not sure about other languages.


#7

Thank u… for this important information…


#8

With regards to RAML 2 HTML - Have you had a look on the existing https://github.com/kevinrenskers/raml2html project?


#9

Yes I have… and it looks pretty good. I may very well use that instead of rolling my own, however I did want to look at using ReactJS + Bootstrap + our own CSS themeing for custom purposes. However that’s a further out, if ever project and am fine with what is there. I think there is work still being done to make it even better. For example it would be nice if there were options to display the request and responses in tabs like how the API Designer does it, and some work around customizing how the Documentation link can be used, such that I may want to pop that up in a dialog or a slide-out panel.


#10

We do have a set of unpublished APIs to automate this process. You can send a RAML and get a ZIP file as response. However, multipart RAMLs must use absolute Urls for includes. We call it Code-Generation-as-a-Service. Let me know if you are interested in more details.


#11

zeeshan, I replied separately, but to share with the group, I think what you are offering is fantastic. However, for larger companies that may have lots of builds, depending on a third party service that is not hosted internally may be an issue for adoption. What about the idea of bundling that service for deployment outside? I am not sure how you would monetize that, or if you would. Maybe a yearly fee to keep updates coming in, etc? I’d also like to see different client side library options. Assuming you monetize it on some sort of yearly support plan, adding these sorts of client side options would be good. For example, in the java arena, a lot of people use Jersey/Glassfish with JAX-RS on the server, and Jersey provides an excellent client side library that can take advantage of the JAX-RS annotated classes/models and bundle up into a nice SDK for the client to use. It would be great to see client side library options like HttpClient, Jersey, URLConnection (no dependencies), etc to choose from as well. Thoughts?