Giter Site home page Giter Site logo

servicewizard's Introduction

ServiceWizard

Automatically generate API documentation and Javascript client code for your Dropwizard project.

Example output

Take for example a very simple ToDo application's API:

@Wizard(name = "ToDos")
@Path("/toDoItem")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public class ToDoItemResource {

	@POST
	@Wizard(
			title = "Create todo",
			description = "Creates a todo item. An ID will be auto-generated for it.")
	@Consumes(MediaType.APPLICATION_JSON)
	public ToDoItem create(@Valid @WizardDesc("The ToDoItem to be created") ToDoItem item) {
		// ...snip...
	}

	@GET
	@Path("/{id}")
	@Wizard(title = "Retrieve ToDo item")
	public ToDoItem retrieve(@PathParam("id") @WizardDesc("The ID of the item to retrieve") long id) {
		// ...snip...
	}
}

Aside from the typical annotations for a Dropwizard project, this class and its methods use the Wizard annotations to add documentation information.

By scanning these annotations ServiceWizard can create an Angular service to consume this API:

angular.module('ToDoSDK')
.factory('ToDos', ['$http', function($http) {
    var urlBase = 'http://localhost:8080';
    return {

        /**
         * Create todo
         *
         * Creates a todo item. An ID will be auto-generated for it.
         *
         * @param data - The ToDoItem to be created
        */
        create: function(data) {
            var request = {
                url: urlBase + '/toDoItem',
                method: 'POST',
                data: data
            };
            return $http(request);
        },

        /**
         * Retrieve ToDo item
         *
         * @param id - The ID of the item to retrieve
        */
        retrieve: function(id) {
            var request = {
                url: urlBase + '/toDoItem/' + id,
                method: 'GET'
            };
            return $http(request);
        }
    };
}]);

It can also create documentation for this API in Markdown:

TodoService

[POST] /todoItem/create

Create todo

Creates a todo item.

[GET] /todoItem/get(id)

Get todo item

Gets an existing todo item by id.

Building from source

$ gradle shadow

servicewizard's People

Contributors

rev-jcb avatar jbauschatz-duplicate avatar forana avatar

Stargazers

John Charles Bauschatz avatar  avatar David Moore avatar

Watchers

David Moore avatar  avatar John Charles Bauschatz avatar James Cloos avatar

servicewizard's Issues

JSDocs standard formatting

Format js method documentation to a standard that JSDoc can use, so that clients have access to other tools with this project

Structure gradle build targets

The build should be structured so that different tasks can be called, and parameters are supplied from the config file.

General log of generation process

There should be some log statements going by as the generation process executes.

This would list what classes are found, what files are generated, and when the process completes successfully.

Content type

For requests that have a body, content-type should be set appropriately.

Is it safe to always set this to application/json? Or should this be set based on the @consumes annotation in the service? If so, should one javascript function be created for each content type in the @consumes annotation?

Docs Resource / View

Resource and/or View that provides an HTML version of the API's documentation, at runtime.

"Auto-generated by ServiceWizard" watermark

Should we include a "watermark" on our generated code that points out the code is auto-generated?

This could be helpful for teams using our project, to keep track of what files not to edit.

Abstract away Dropwizard implementation

The ServiceLocator class assumes annotations from javax.ws, but the framework should support Spring service as well. ServiceLocator should be make abstract with subtypes targeting particular web frameworks.

Route field: Permission required

Could be set to "admin" or "group member" or "item owner", etc. Basically designating a field to say "hey this route only works for admins" instead of needing to shove that in the description.

Dropwizard version support?

What version will this specifically target? 0.8.4 is the current "latest", but there's a 0.9.0-rc4. The relevant packages have not changed since 0.7.0, but I feel like 0.8.X is a more reasonable "floor" for support.

Project license

It's probably time we discussed how to license this project.

Base class for generators

There's some shared code between the markdown and HTML output that could be pulled into a common supertype.

I'm not sure how much can (or should) be done to unify the generators since they may behave so differently - for example Angular service output makes multiple files while documentation targets a single file. If generators are not interchangeable they should not be given an common type, so this should be investigated.

Generate core angular module

The generated angular services draw their module name from configuration, but currently it is assumed that the angular model itself is implemented by the client code. This means that our angular cannot be packaged as-is in SDK form.

We should generate an angular module, into which the services are injected. This module can also include standard utility functions usable by the services. For example, we need a standard and readable way to template URL's from route parameters.

Unit tests

We need 'em.

They should especially verify the Locator behavior.

Path variables

ServiceWizard should support path variables, for example "/todo/{id}/update". Variables passed to the Angular service calls should be bound into the url's template.

Support for introduction/overview text

Somehow allow a string to be set that counts as introductory text - this would be placed into a comment block at the start of the angular, a header section in the markdown, and a section in the HTML.

Documentation for Bean types

This is a bit way out there, but something I've been thinking about for cirdan. Consider the following:

@WizardType
public class ExampleBean {

  @Wizard(desc = "I am some boolean that does a thing", default = "false")
  private boolean something;

  @Wizard(desc = "This is definitely a text field")
  private String anotherThing;

  /* snip */
}

Then, we could have a section in the markdown and HTML output that describes these structures.

Build is broken

At some point a commit seems to have broken the build.

The Reflections package is no longer able to scan the com.sampleapp package at runtime, resulting in no output. It's possible that I committed a breaking change at some point but had old class files locally, or something, which kept me from discovering this until recently.

Clean up HTML output in default template

The HTML documentation is an eyesore and needs to be prettied up.

I'm not sure which should be more prominent, visually: the title of the route or the URL itself.

The HTTP verb should be moved out of the header level and maybe down below the description - similar to where @params would appear in a Javadoc. The same could be done for the query params, etc.

Sample app frontend

We should have a simple angular frontend app for consuming the Todo API.

This will demonstrate the whole workflow of ServiceWizard including deploying and using the Angular code.

Smurf typing on annotations

Having to type ServiceWizard before each and every annotation feels wrong. All of dropwizard's underlying libraries' annotations are grouped by package, but have generic names (@Consumes, @Timed, etc).

Maybe change @ServiceWizardService and @ServiceWizardMethod to something like @Service and @Method? There's at least one major conflict with that (Spring), but I feel like we can come up with a synonym for that that isn't jarring.

Dropwizard does not accept GET with body

When a Dropwizard method uses GET and expects a request body, the generated Angular code doesn't create a valid request.

Dropwizard IS accepting GET requests with a body from other sources, such as a python script I've used for integration testing. But the generated Angular needs some configuration for Dropwizard to see the body.

Javascript parameter name collision

It's possible for the generated angular service functions to have collisions in the parameter names. If a path parameter were named "params" or "data", that would collide with the generated parameters by those names.

I would propose throwing an error on generation that says there's a collision and generation cannot be performed. OR we could name the offending parameter "data2" or "params2" or somesuch.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.