But what about reimplementing the same concept over and over again? Like if your API returns tables, then you need to invent a format, write documentation instead of linking to it etc.
On the other hand, such standarizations tend to become overengineered monstrosities that no one wants to use in the real world. An example of this seems to be JSON HAL which I decided is too complex to implement in an API.
Nice website by the way. I planed to build something like that,where developers could find specs instead of trying to reinvent hot water.Well done. A search feature would make it even greater, where one could search by category,theme,or tags. Example: I want to implement security in my website. What options do I have ?,what spec can I implement or is there an implementation of that spec already available for my programming language ?... You're on to something here, definitely.
I'm not affiliated with the authors in any way. I stumbled on the page when looking to use a standard JSON representation of tables in an REST API (and I'm still not sure I should use this).
I may be missing something, but how do you format data associated with a schema defined this way? Do we assume it will be just a 2D json array? Or is that outside the scope of this project?
6 comments
[ 1.6 ms ] story [ 28.6 ms ] threadThese are specific use-cases, and in no way encumber other uses of JSON.
Personally, I'd love to see a universal format that all database vendors use, instead of vendor-specific DDL.
On the other hand, such standarizations tend to become overengineered monstrosities that no one wants to use in the real world. An example of this seems to be JSON HAL which I decided is too complex to implement in an API.
[0] http://stateless.co/hal_specification.html