If you're trying to solve problems caused REST not being a protocol, why not
settle with defining -- or better yet, using an already defined -- protocol?
Really, there were plenty of good RPC protocols, starting with XML-RPC and
a little more modern incarnation of JSON-RPC 2.0.
On the other hand, REST allows exactly what changes to the API that don't
require modification of remote clients? Because hypertext only allows to move
boundaries where data is split into chunks returned at one call, not how the
data looks like, and it's the structure of the data that mainly changes with
API.
REST allows you to change the structure of the data as well, for instance using linked-data specs, like schema.org. However, in practice it's very difficult and also REST makes it very difficult to evolve different parts of the API, asyncronously.
Here we propose Introspected REST which gives you much more flexibility and solves such issues through introspectable content provided by various MicroTypes the API uses.
4 comments
[ 3.4 ms ] story [ 25.8 ms ] threadHere we propose Introspected REST which gives you much more flexibility and solves such issues through introspectable content provided by various MicroTypes the API uses.