I'm looking for an efficient way to generate API documentation in a readable format, from the generated files from Cloud Endpoint (Java). The generated files are either:
- my_api.api
- my_api*.discovery
Something that looks like this:
- https://github.com/kevinrenskers/raml2html#example-output
Swagger, API blueprint and RAML are all nice options, but don't seem adapt well to endpoint generated API descriptor files.
What methods are you using?
Unfortunately we (Apiary) do not actually offer any code generation tool at the moment for API Blueprint.
If you are looking for a way how to generate a description of your API from the code then API Blueprint isn't probably the best choice as we believe it should represent the contract between everybody involved in the API design lifecycle. This is also the reason why we have built the testing tool – Dredd – https://github.com/apiaryio/dredd
With Dredd you can test your API implementation is matching to your blueprint. It wouldn't make much sense if the blueprint would be generated from the implementation.
Hope it clarifies.
Related
I am currently learning Camel, and have a specific project in mind that requires a Websphere MQ back-end, but I can't use JMS components, since I need a lot of non-jms headers, like MQIIH.
I found the camel-wmq project.
Is it the recommended solution ? Is it any good ?
You don't need to use jms. WMQ has a client API. Just download the wmq client jars and put them in your project and use them together with your Camel routes. You will probably put the wmq client code in a processor class or something similar. Off course best to test to put a message on a queue manually via RFHUTIL or something similar as a client so you are sure the environment setup is correct.
The suggested way of working with WMQ has always been through the JMS component since it enables you to painlessly switch to other providers if the need arises.
However, if you need to use some WMQ-specific function then my suggestion would be to extend the camel-wmq library - it contains only a subset of features supported by WMQ and does not support MQIIH headers that you need. Adding functionality to a component would probably involve more work than the solution Souciance Eqdam Rashti suggested but it would be a cleaner solution and more in line with Camel's philosophy. Also, you'd be giving back to the community and thus help make Camel a better tool for everyone :)
I would also suggest you go through the IBM MQ discussions on the Camel's official user group mailing list and see if you can salvage anything.
I'm working on an app written in Codename One together with the parse4cn1 library, the combination of which is a real pleasure to use. However, I need support for a few things in parse4cn1 that are not implemented, most importantly ACL and was wondering if Chidiebere has any hints on how to do this (e.g. how did you implement parse4cn1 yourself - from scratch or copying the open source Parse SDK for Android)? If I manage to do something of a decent quality I will try to share back. Thanks in advance
I never got around implementing ACLs (it's still on the TODO list). parse4cn1's interface closes resembles the Parse Android SDK interface and I'll like it to stay that way for convenience. In this case, the interface of interest would be the ParseACL which is documented here.
The actual implementation will need to be done via REST API calls.
Things to bear in mind:
We use the Android SDK API simply for defining methods and signatures for the corresponding class in ParseACL but do not use the SDKs for anything can be be done via REST.
By design, any calls requiring the master key will not be supported in parse4cn1 due to security considerations. If really needed, the functionality should be exposed via server-side cloud code.
Pull requests without unit tests for the added functionality or breaking existing tests will be rejected.
See also the Contributions section of the parse4cn1 github repo.
Good luck with your implementation and I hope to see a PR from you soon ;)
It was implemented from a Java port on top of the REST API's here but was later modified to use the SDK's to allow things like push (which are now no longer relevant).
In the past I just contributed pull a request to the project to get the fixes/features I needed. It was really easy to work with and compile.
I am trying to write a Camel route to get JMX data from an ActiveMQ server through the Jolokia REST API. I was able to successfully get the JSON object from the ActiveMQ server, but I am running into an issue where I cannot figure out how to parse the JSON object in my Camel route. Camel is integrated with Jackson, Gson, and XStream, but each of those appear to require an extra library that I do not have. Camel also has support for JSONPath, but it requires another library that I do not have. All of my research so far seems to point to using a new software library, so I am looking for someone who knows a solution to possibly save me some time from trying several more dead ends.
The big catch is that I am trying to parse JSON with something that comes with Java/Camel/Spring/ActiveMQ/apache-commons. I would prefer a solution that only uses Camel/Spring XML, but another solution using Java would work (maybe JXPath with Apache Commons?).
The reason I am trying to use libraries that I currently have is the long process that our company has for getting new software libraries approved. I can wait several months to get a library approved or I can write my own specialized parser, but I am hoping there is some other way for me to extract some of the information from the JSON object that I am getting from the Jolokia JMX REST API in ActiveMQ.
There is no JSOn library out of the box in Java itself. But there is a RFE to maybe add that in a future Java release, maybe Java 9.
So if you want to parse json, you need to use a 3rd party library. So you better get your company to approve a library.
camel-core 2.15.x has a json scheme parser we use to parse the component docs json schemas that is shipped now. But its not a general purpose json parser, but can parse simple schemas.
Its at org.apache.camel.util.JsonSchemaHelper
Firstly, I'd like to know how to find this out for myself next time. If not, then can somebody tell me?
The reason I want to know is because I want to use the #JsonIdentityInfo annotation on my Cloud Endpoints entities to deal with recursive serialization, but it doesn't compile. I guess this would mean it's some Jackson version less than 2.0.
You should not use repackaged libs - they are for internal GAE use only. They are not part of official API and can change at any time.
Include your own Jackson jar in your project.
Like Peter says, include your own Jackson jar. Make your code use this Jackson library. GAE will use their repackaged JSON parser or whatever they change it to (even not necessarily Jackson). That is of no concern to your project. GAE has no reason to look for Jackson annotations on your Entity classes - only your source code should tell only your Jackson jar to do that.
We have a library with very complex logic implemented in C. It has a command line interface with not too complex string-based arguments. In order to access this, we would like to wrap the library so that it can be accessed with simple XML RPC or even straightforward HTTP POST calls.
Having some experience with Java, my first idea would be
Wrap the library in JNI/JNA
Use a thin WS stack and a servlet engine
Proxy requests through Apache to the servlet engine
I believe there should already be something simple that could be used, so I am posting this question here. A solution has the following requirements
It should be deployable to a current linux distribution, preferrably already available via package management
It should integrate with a standard web server (as in my example Apache)
Small changes to the library's interface should be manageable
End-to-end (HTTP-WS-library-WS-HTTP) the solution should not incur too much overhead, but reliability is very important
Alternatively to the JNI/JNA proposal, I think in the C# world it should not be too difficult to write a web service and call this unmanaged code module, but I hope someone can give me some pointers that are feasible in regards to the requirements.
If you're going with web services, perhaps Soaplab would be useful. It's basically a tool to wrap existing command line applications in SOAP web services. The web services it generates look a bit weird but it is quite a popular way to make something like this work.
Creating an apache module is quite easy and since your familiar with xmlrpc you should check out mod-xmlrpc2. You can easily add your C code to this apache module and have a running xmlrpc server in minutes
I think you may also publish it as a SOAP based web service. gSoap can be used to provide the service interface out of the library. Have you explored gSOAP? See http://www.cs.fsu.edu/~engelen/soap.html
Regards,
Kangkan
Depends what technology you're comfortable with, what you already have installed and working on your servers, and what your load requirements are.
How about raw CGI? Assuming the C code is stateless between requests, you can do this without modifying the library at all. Write a simple script which pulls the request parameters out of the CGI environment, perhaps sanitises the input, calls the library via the command-line interface, and packages the result into whatever HTTP response you want. Then configure Apache to dispatch the relevant URL(s) to this script. Python, for example, has library support for XML-RPC, and so does every other scripting language used on the web.
Servlets sound like overkill, but for instance if you want multiple requests per CGI process instantiation, and don't feel like getting involved in Apache configuration, then it might be easiest to stick with what you know.
I'm doing a similar thing with C++ at the moment. In my case, I'm writing a PHP module to allow PHP scripts to access the logic in my C++ library.
I can then use whatever format I want to allow the rest of the world to see it - initially it will just be through a PHP web application but I'll also be developing an XML-RPC interface.
If you're going down the JNI route, check out SWIG.
http://www.swig.org/Doc1.3/Java.html
Assuming you have headers to project bindings with, swig is pretty easy to work with.