You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Jens Geyer (JIRA)" <ji...@apache.org> on 2017/06/03 09:48:04 UTC
[jira] [Commented] (THRIFT-4220) Allow Service calls to be made
using TSimpleJSONProtocol (using Simple JSON)
[ https://issues.apache.org/jira/browse/THRIFT-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035915#comment-16035915 ]
Jens Geyer commented on THRIFT-4220:
------------------------------------
TSimnpleJSON was never intended to be used as means of transport in Thrift. I don't see the value w/regard to the [Thrift Goals|http://thrift.apache.org/about], especially since we already have TJSONProtocol which adheres much more to them:
{quote}
Apache Thrift aims to embody the following values:
• Simplicity Thrift code is simple and approachable, free of unnecessary dependencies.
• Transparency Thrift conforms to the most common idioms in all languages.
• Consistency Niche, language-specific features belong in extensions, not the core library.
• Performance Strive for performance first, elegance second.
{quote}
TL;DR: I tend to disagree.
> 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
> Fix For: 1.0
>
>
> https://blog.parsable.com/using-human-readable-json-endpoints-with-thrift-for-free-774ba505c893
> 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": "devansh@wi.co",
> "password": "password"
> }
> }
> {code}
> RESULT:
> {code}
> {
> "method": "login",
> "result": {
> "success": {
> "authToken": "some_auth_token",
> "currentUser": {
> "id": "6a6c982b-62f9-46d2-aff9-bd3a1cdf43f9",
> "email": "user1@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
(v6.3.15#6346)