4 ms·

I've started doing just that but I have a micro-services architecture so I need to implement the custom encoding schema on multiple stacks (i.e. java, python, g

I've started doing just that but I have a micro-services architecture so I need to implement the custom encoding schema on multiple stacks (i.e. java, python, go) which takes time. Being non-standard the external consumers will have to use or reimplement our encoding schema. Feels like reinventing the wheel. I'm still can't get why nobody published a RFC for this issue. PayPal[0] uses query string extensively and still the format is driven by example and implementations(i.e. their SDKs) [0] https://developer.paypal.com/docs/classic/api/NVPAPIOverview/ https://developer.paypal.com/docs/classic/api/NVPAPIOverview...

beat 10y ago
Are you using the same data format for all platforms? You could try writing a test framework in a BDD-language like Cucumber that can be ported to multiple languages, and code a language-specific parsing library against that. It's still work, but not that bad, and it would keep things consistent. Even without that, passing a parameter as url-encoded json isn't that awful.
dragonwriter 10y ago
> Feels like reinventing the wheel. I'm still can't get why nobody published a RFC for this issue. They have, back in the "XML is the king of data formats, and WebDAV is the way to build web applications" days. (It sounds something like either the SEARCH or REPORT HTTP method defined for WebDAV.) Someone proposed a generified version of SEARCH but it didn't go anywhere, that and a few other bits of WebDAV really could use being detached and made useful separately for generic web content.