For any developer who has ever worked with SOAP you know about WSDLs. These standardized files could provide information to an application or and IDE which the developer could then use to easily select an action to do. In the era of declining SOAP usage and the rise of the RESTful APIs it’s time to start thinking about how to make REST even easier to consume than it already is. Easier than easy… yes, easy peasie lemon squeezy.
I won’t lie my first experience with SOAP was a nightmare and even worse I was doing it with PHP and a toolkit that was clearly developed by someone who didn’t want anyone to use php to use their service. So my first experiences were bitter to say the least. But as I worked on other project I foudn other developers using other platforms/frameworks (like .NET) who spoke highly of their experience with SOAP. So that made me ask the question, “What was I missing out on?” The truth was a lot actually. When I saw how easy it was to consume a SOAP service in .NET it seemed to good to be true. But with SOAPs decline in favor of RESTful services the shift went back to something I was ultimately more comfortable with given my experience with SOAP.
So now to the meat and potatoes. What we needs is a good tool that make creating an API easy. BUT WAIT JOE MY COMPANY ALREADY PURCHASED AN ESB AND I HAVE TO USE IT. Well that sucks for you because the big thing that most ESBs I’ve used fail on is providing clear documentation on how to use the service and if it’s JSON based there’s no file generated for a developer IDE to consume. And that’s what we need, an application that allows developers to connect to any data store, provides an easy and intuitive method on configure what should be exposed, what should be auto set, what needs to be validated as well as set up authentication for you and auto-generate documentation and a consumable description of the service that an IDE can use to make connecting to the API easy. We need Deejers (DJRS).
Swagger has already done most of the hard work for this and I think we just need to take it to the next level.
So that’s the goal and I’m starting to build it now and since I’m currently obsessed with Meteor I’m going to use it to build it. Check if anyone has done that yet… NOPE.
Goals:
- Self Documenting (Swagger)
- Built in analytics tools
- User Access Management
- Easy to Understand UI (For API management)
- Auto Generated SDKs for languages (Swagger format has consumable client libraries for most languages)
- Back-end should connect directly to Data-store
- Should support major data store formats
- Deployment on on Cloud Foundry will be easy
- Caching – with query time cache conditions and customization cache times for each end point
- Support major security formats (Basic, OAuth, JWT ect…)
- Availability to increase number of running nodes to scale up in high demand situations
- User can configure the application for any table available:
- Auto Generate field on condition
- Designate Required Fields
- Data Type
- Schema (Global and per table)
Steps:
- Build app that connects and has CRUD access to most common DB formats
- Auto-generate basic yaml based on connected datastores
- Provide swagger-like endpoint manager to define options
- Generate YAML or standard Swagger Config file for Service
- … more… but let’s start with that.
Tell me what you REALLY think...