In the complementary currency movement most of us have been so preoccupied with our software platforms that we haven't had the capacity to build apps; when apps are built, they are tightly coupled to one platform, making them difficult to share.
Building a mobile phone app means defining an API in which all the objects to be manipulated are described field by field. The app and the server send these objects back and forth, and, knowing the fields, the app can apply the data objects to built in templates to display them. In fact the whole user experience is determined by the javascript css and templates of which the app is comprised.
The different community exchange platforms have very similar data types, and need a similar user experience, but they do have slight differences which means a 'highest common factor' API would be extremely minimal. What's needed therefore is known as a 'self-describing REST API'.
It turns out however that REST is an extremely diverse school of how to write applications. The original specification of REST had everything being self-described, but this was rather cumbersome for projects with very specific functions, and nowadays almost nothing does it the original way, there are no standards and conventions are weak.
So I feel a bit in the dark as I'm working with two volunteers to build a mobile app for community platforms and community exchange platforms. Version 1 will handle 4 resource types, offers, wants, transactions, and members, and the app will know enough about each to provide a nice user experience.
I attempted to define the API on Swagger but realised that what I want to describe is the very abstraction of what Swagger is doing. Each of my four resources have different fields and operations on different platforms, but they are all described in exactly the same way - but what formal language exists for meta-swagger, and do I have time/inclination to learn it, and if I did, is anybody likely to read it?
I've written a small php application to sit between the web platform and the Client, serving up the REST API. Each platform that wishes to use it must extend a base object for each of the four REST resources. Each platform author must defines the resources' fields, handle user authentication, and read and write to its database.
Since the resources are described so generically, additional resources could easily be added, although the client won't know enough about them to make them user-friendly beyond the standard operations of listing, filtering, sorting, creating, viewing, updating, deleting. The platform can also define operations on each resource such as user->contact, or transaction->sign, or blog-post->like, which would appear as buttons on the app, so there's quite a lot of flexibility there.
In fact I'm wondering if this might have wider applications for building clients which simply browse and manipulate REST data. I can't believe nobody else is doing this.
Just to clarify, the long term vision is to disintermediate these web platforms entirely. The politics of community network software revolves around what umbrella groups communities are in and what platforms they have been offered. I'm proposing that eventually the clients (meaning the mobile phone app) would access myriad data services, such as accounting and offers/wants directly, without cumbersome platforms in the middle. Step by step.
Comments