A language for describing resource-oriented APIs & turning them into Swagger or resource diagrams. Oriented around the concepts we want to expose in the APIs.
In the chance that the standards did not capture a certain use case, a service owner should be able to override the structure in order to support their feature.
This should be called out in spec review and possibly remedied (discouraged), but in Buyer API's case, we had a valid use case and the latency for Reslang supporting it was too high.
Plus, placing the burden of changing our API standards on an IC who just wants to ship a feature is bad work order. No IC besides me is insane enough to do this. What this means is that if the standard is hurting more than its helping, you'll have no way of knowing, because people will avoid the problem by compromising on their interfaces.
In the chance that the standards did not capture a certain use case, a service owner should be able to override the structure in order to support their feature.
This should be called out in spec review and possibly remedied (discouraged), but in Buyer API's case, we had a valid use case and the latency for Reslang supporting it was too high.
Plus, placing the burden of changing our API standards on an IC who just wants to ship a feature is bad work order. No IC besides me is insane enough to do this. What this means is that if the standard is hurting more than its helping, you'll have no way of knowing, because people will avoid the problem by compromising on their interfaces.