When @Bart_Elia presented the new REST interface in his famous REST Novel Overview, he was concerned how it might be received:
Level unlocked. REST has been a HUGE addition to the Kinetic platform! It was a great evolution from the .NET Object model. The landing spot at the time was well balanced. There are now new challenges like APIs for large objects.
Microsoft has a really nice guide about API Design and in it they have this quote:
In 2008, Leonard Richardson proposed the following maturity model for web APIs:
- Level 0: Define one URI, and all operations are POST requests to this URI.
- Level 1: Create separate URIs for individual resources.
- Level 2: Use HTTP methods to define operations on resources.
- Level 3: Use hypermedia (HATEOAS, described below).
Kinetic is at level 2, as are most commercial software companies who have REST-enabled their products. It is a natural evolution and I’m not throwing shade here.
This thread is showing us why the RESTafarians would now be saying, “We told you so.” But most REST purist are such jerks, nobody would listen to them anyway.
Not a jerk (most Canadians without a puck are generally pretty nice), is a blogger/YouTuber named Derek Comartin. A few years ago, he did a series about HTTP APIs that does a really nice job explaining how to get to the next maturity level, which is HATEOAS - Hypermedia as the Engine of Application State.
This is a BIG step however. But one could imagine that the action bar (the ‘+’, and other icons) is driven by the server and not directly in a layer with rules. If an action link appears in the response, the icon appears, if not it doesn’t. (Mind you, we’re not talking security, just client behavior. All security would still be enforced at the server.) The landing pages are very well suited for HATEAOS since the action links are basically there.
For a large order, the response would have most of the header and links for options: open lines, all releases for a line, etc. Now the download size is potentially much smaller. Kinetic could certainly come up with a different UI that would allow much less data to be returned for specialized functions that manage only releases for example, but some thought is required for concurrency.
Again, this is a natural progression from a system that had all the bandwidth of a LAN and a lot of memory at the workstation to a higher latency network with the server further away and the reduced memory footprint of a browser. Epicor will evolve here too once the UI continues to settle.