[
https://issues.apache.org/jira/browse/THRIFT-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733107#comment-16733107
]
James E. King III commented on THRIFT-4220:
-------------------------------------------
[~devansh_gupta91] Field names are allowed to change without any upgrade
impact, so your specification violates a thrift invariant. What I would suggest
if you are still interested is to modify the proposal so the field numbers are
encoded in the key, for example find a character that is not allowed to be used
in a field name and make that a delimiter, then put in the field numbers.
I like your proposal overall otherwise. Ideally at the beginning it would have
made more sense to have TJSONProtocol be verbose, and have a
TCompactJSONProtocol which omits the field names and just outputs the values
(as it does today). But that's not what happened. Might I also suggest you
think about using YAML instead. I know having the field numbers is a drag but
the separation of field name and slot number in a struct is important for
upgradeability.
{noformat}
---
1#method: "login",
2#result:
1#success:
1#authToken: "some_auth_token"
...
{noformat}
> Allow Service calls to be made using TSimpleJSONProtocol (using Simple JSON)
> ----------------------------------------------------------------------------
>
> Key: THRIFT-4220
> URL: https://issues.apache.org/jira/browse/THRIFT-4220
> Project: Thrift
> Issue Type: New Feature
> Components: Wish List
> Affects Versions: 1.0
> Reporter: Devansh Gupta
> Priority: Major
> Fix For: 1.0
>
>
> https://github.com/degupta/human_readable_json_protocol
> If we publish our Services/APIs as Thrift today you can't make requests using
> simple Human Readable JSON. This means publishing our APIs to third party
> users means they have to
> 1. Know how to use Thrift
> 2. Have all the Thrift definition files or the generated code
> Or we have to build Libraries for each of the platforms we want to support.
> This is not always possible.
> I propose we do something like this:
> {code}
> exception SystemException {
> 1: i32 errorCode,
> 2: string message,
> }
> struct User {
> 1: string id,
> 2: string email,
> 3: string name,
> 4: i64 validatedAt
> }
> struct LoginResult {
> 1: string authToken,
> 2: User currentUser
> }
> service AuthenticationService {
> LoginResult login(1: string email, 2: string password) throws(1:
> SystemException err)
> }
> {code}
> Request Format:
> {code}
> {
> "method": "METHOD_NAME",
> "arguments": { ... }
> }
> {
> "method": "login",
> "arguments": {
> "email": "deva...@wi.co",
> "password": "password"
> }
> }
> {code}
> RESULT:
> {code}
> {
> "method": "login",
> "result": {
> "success": {
> "authToken": "some_auth_token",
> "currentUser": {
> "id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
> "email": "us...@wi.co",
> "name": "user1",
> "validatedAt": 0
> }
> }
> }
> }
> {code}
> This uses the JSON generated by the JSON Generator as "metadata" to figure
> out the Field Keys and Types.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
