I am using Java code in an adapter, however I can't find the API doc reference of the classes I receive in Java. i.e. com.worklight.common.js.util.JSObjectConverter
Is this API documented anywhere?
You can see server side Java API reference here - http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.apiref.doc%2Fapiref%2Fr_worklight_java_server_side.html (open the "Java server-side API" section in the left frame).
The specific API you're asking about (JSObjectConverter) is internal undocumented API therefore you'll not find any documentation for it.
Related
I'm new to this api documentation era.
Vising this api documentation, I get to post and query data. I understand that's a demo api documentation with swagger.
But what happens with real world API documentation? do I have a documentation in demo.api.myawesome.com and actual api on api.myawesome. com using different data stores?
But again digging deeper, I got to find out that an api can be self documenting using swagger libraries. This seems like both api and documentation are using the same data store which can't be the case.
What am I missing here?
From the Swagger website:
Swagger is a set of rules (in other words, a specification) for a format describing REST APIs. The format is both machine-readable and human-readable. As a result, it can be used to share documentation among product managers, testers and developers, but can also be used by various tools to automate API-related processes.
So yes, it uses the same "back end" as the actual API. It's just visualizing it, allowing you to interact with it via the Swagger UI.
If you mean Swagger UI - the "try it out" button sends requests to the server specified by the host property in your spec. If host specifies your production server, requests will be sent to production; if it points to a sandbox, "try it out" will use the sandbox. You may have a version of the spec for internal use that points to production, and a public version that points to sandbox.
Note that Swagger supports authentication as a way to ensure that only authorized users (e.g. your actual customers with valid credentials or API keys) can make API calls.
You can omit host from the spec to disable the "try it out" functionality - this way you can still have the API docs, just without the interactive part.
I've recently come across the term api and from what I have known api is a interface that connects/integrates between two programs and it can run on any platform.
And again from java we know that it turns it's source code into bytecodes and this bytecode can run on any platforms since it is platform independent.
So my question is does api work/run just like as a bytecode to provide multi-platform functionality
And if not is there any similarities between them or thier process? If please anyone could explain it to me it would be a great help. Thanks in advance.
API does not work like bytecode
Actually, API and Bytecodes are a completely different thing
For Bytecode,
let's try to understand it in java. java compiler compiles a java program then produce bytecode. Then the bytecode is interpreted by java interpreter in different machines and generate different executable files as the requirement of different machines and os.
this is how java maintains it's multi-platform property
Now, API,
API stands for Application Programming Interface. An API is a software intermediary that allows two applications to talk to each other. In other words, an API is the messenger that delivers your request to the provider that you’re requesting it from and then delivers the response back to you.
there are many types of API's out there
but I think you are referring to Web API and it's multi-platform functionality and how it works.
A Web API is an application programming interface for either a web server or a web browser
A Web API works as server-client architecture.
client request to server through HTTP protocol, server responds to client through HTTP protocol
actually whole api service is provided through HTTP protocol, and this api service can provide to any device using HTTP protocol
this has nothing to do with bytecode
The functions for operating the restful api is quite same. Is there any project that can generate the source code for different platform such android,ios and backend stuff.
I suggest you to use API description languages such Swagger ou RAML.
After having described your RESTful application with a language like this, you will be able to generate things like server skelekons and client sdks with different technologies and languages. You can even generate documentations.
With Swagger, swagger-codegen will do that. swagger-ui may also interest you for the documentation part.
To finish, I would like to mention the Restlet studio that allows to define graphically and quickly the structure of RESTful applications and generate then the corresponding Swagger and RAML contents. The APISpark plaform provides a mecanism to introspect Restlet applications and generate the corresponding contents with these languages. It also allow you to generate a set of server skelekons and client sdks.
Hope it helps you.
I will suggest you to use Spring RESTful webservices starter kit. Which will manage your back-end with centralized database. Also Spring has its own android libs to communicate with REST Apis.
The RESTful Web service APIs are implemented using Restlet. I need to generate the API documentation for these. Rather than starting with a separate document, I am evaluating if this can be generated from the source code annotations itself.
I looked at Swagger and enunciate. Swagger seems to be based on the JAX-RS specification. Enunciate looked a little more promising as there is an FAQ that mentions how to generate for non JAX-RS implementations but there is no help.
Are there any tools (or if the community has used any) for generating API documentation from Restlet annotations?
Has anyone integrated Restlet with enunciate for generating documentation?
Restlet now supports the ability to generate either corresponding Swagger and RAML contents based your application at runtime.
Following docs could help you:
For Swagger (extension org.restlet.ext.swagger): see http://restlet.com/technical-resources/restlet-framework/guide/2.3/extensions/swagger
for RAML (extension org.restlet.ext.raml): see http://restlet.com/technical-resources/restlet-framework/guide/2.3/extensions/raml
You can then leverage tools from the tool community to generate your API documentation. You could consider Swagger UI that is a great tool to display online what an API provides and interact with it.
Hope it helps you,
Thierry
If you have ever used the Flickr API, you'll be familiar with their API Explorer. It is an awesome tool, that allows you to view the documentation for each API method, and the killer feature, being the execution of that API method (with a form to populate any request parameters). It even picks up when you are logged in, and completes the authentication part on your behalf. Gowalla has a similar API Explorer that is also really good.
Are there are tools for WCF that will auto-generate such an API Explorer, free or commercial?
Currently, we use Fiddler to build the JSON requests, but I would like to publish these service contracts, and allow potential developers to play around with them via a web based API explorer.
I am aware of the WCF Web HTTP Service Help Page, which I am using (and is awesome), but it is the API Explorer part that I am interested in.
You may want to look at I/O Docs - an open-sourced interactive documentation system for RESTful web APIs that any API owner can use to deploy for their own documentation. It runs on Node.js and uses Redis as a data store.
https://github.com/mashery/iodocs
Example: developer.klout.com/iodocs, developer.rottentomatoes.com/iodocs
It uses JSON schema based files to define API endpoints, method and parameters. Based on these JSON files, it generates a client interface that developers can use to learn and explore your API. API calls can be executed directly from the documentation interface, producing formatted responses.
It's Open-sourced, so you can be assured of regular updates and improvements. In fact this past weekend, Brandon West from SendGrid (who use I/O docs to power their documentation), created and open sourced the UI to create/edit the JSON schema files for I/O Docs. So you don't have to manually create the JSON files anymore.
https://github.com/brandonmwest/iodoctor
Not exactly what you were looking for, but....
WCF provides something called the WCF Test Client, for this purpose.
If you install Visual Studio, you get it. For example, for VS2008, installed in the usual place, you can find the WCF Test Client (WcfTestClient.exe) in the following location:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\
Take a look at Apigee: http://apigee.com/