I’ve been heartened by what reception this product has had. Granted, said reception is small, but that was my intent with the beta launch and I have confidence that it only grows from here.

Updates

Since last I posted here there have been several platform updates.

  1. The gateway service should now behave in a more stable way.
  2. I’ve added support for deleting customer APIs. This is a logical delete, so they are recoverable. Send me an email and I can make something work.
  3. Documentation with some sample calls has been written
  4. I stood up some other backend related items

Soon To Come

HUGE updates coming to the generator this month.

One of the goals of the platform is to provide fully REST compliant services. What currently exists is rough but generally functional RESTish generated services. I am hard at work with a rewrite of the backend that better aligns HTTP verbs with the data structures and calls. Once complete, generated services will be fully Level 2 compliant with the Richardson REST Maturity Model. This will include support for both json and xml acceptance types, include paging for calls on collections, filtering and searching of collections, data shaping with url parameters, and come with more complete HTML status codes.

This will also come with more model definitions and UI on the portal to make those models obvious to users. I hope to deliver a SwaggerUI implementation but that may slide into October.

This is a major refactor and extension but lays groundwork that will be integral to the overall value I hope to provide.

Known Issues Experienced by Beta Users

There have been several users logging in to try out some api creation, and a couple of failures as well. The most prominent is actually a failure where a bug in the parsing dlls do not recognize a property mapping in the Open API spec. This specifically refers to the a ref within a schema definition. These APIs will fail to generate for now, but that type of nested foreign key relation isn’t something best suited to this application. That is a feature on the roadmap though, so look forward to that in the coming month or two.

Another issue I’ve seen in the logs is attempts to use an enum in a schema definition. While formally supported the spec, it was selectively deferred in this iteration of the code generator on our backend. However, enums would just be mapped to ints at the lowest implementation level, so you could treat it as an int in your applications, and map that to an int in the schema definition for now. Not ideal, but it would be functional. Mapping to an enum and enforcing it on our backend in the current generator would imply another table and a maintenance service exposed, which reduces flexibility on the code side of the equation.