[ 
https://issues.apache.org/jira/browse/HDFS-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148883#comment-13148883
 ] 

Tsz Wo (Nicholas), SZE commented on HDFS-2316:
----------------------------------------------

Hi Alejandro,

> 1. Case insensitivity of the param names/values.

Let's follow HTTP/1.1.  They have stated it in the spec.

> 2. Inconsistency on the JSON responses names:

They are indeed consistent: If the return type is a JSON primitive type 
(string, boolean or number), the format is 
{noformat}
{"type": <TYPE>}
{noformat}

If the return type is a class but not an array, then the format is

{noformat}
{
  "Class":
  { 
    "FieldA": <TypeA>,
    "FieldB": <TypeB>,
    ...
  }
}
{noformat}

If the return type is an array, then the format is

{noformat}
{
  "Classes":
  { 
    "Class":
    [
      { 
        "FieldA": <TypeA>,
        "FieldB": <TypeB>,
        ...
      },
      { 
        "FieldA": <TypeA>,
        "FieldB": <TypeB>,
        ...
      },
      ...
    ]
  }
}
{noformat}

BTW, there is a typo in your comment: There is "Token:" in the 
GETDELEGATIONTOKEN return type, i.e.
{noformat}
 {"Token": { "urlString" : "<DT>" } }
{noformat}

Okay, just found out that GETHOMEDIRECTORY does not follow above rules.  "Path" 
should be "string".  But it seems that "Path" makes more sense, what do you 
think?

I did use function names in an earlier implementation but changed it to 
type/class name since it seems that return types should not associate with 
function names.  Just like in Java, you won't put the method name in the object 
of return class.

> 3. FileStatus does not have symlinkPath for symlinks.

Yes, symlink is optional.  I have not included it in the doc.  BTW, how about 
calling in "symlink" instead of "symlinkPath"?

> 4. FileStatus permission is a String but the permission parameter is a short

If we use short, then the octal 777 will be shown as 511, which seems very 
confusing.  So, string is used for representing octal.  In the url, it is 
actually a string as everything is a string.

> 5. The encoding of the delegation token, both as parameter and as response is 
> not defined.

It use Hadoop delegation token encoding, i.e. Token.encodeToUrlString() and 
Token.decodeFromUrlString(..).

> 6. The final doc that gets checked in should no include authors, ...

Agree.
                
> webhdfs: a complete FileSystem implementation for accessing HDFS over HTTP
> --------------------------------------------------------------------------
>
>                 Key: HDFS-2316
>                 URL: https://issues.apache.org/jira/browse/HDFS-2316
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>            Reporter: Tsz Wo (Nicholas), SZE
>            Assignee: Tsz Wo (Nicholas), SZE
>         Attachments: WebHdfsAPI20111020.pdf, WebHdfsAPI20111103.pdf, 
> WebHdfsAPI20111111.pdf, test-webhdfs, test-webhdfs-0.20s
>
>
> We current have hftp for accessing HDFS over HTTP.  However, hftp is a 
> read-only FileSystem and does not provide "write" accesses.
> In HDFS-2284, we propose to have webhdfs for providing a complete FileSystem 
> implementation for accessing HDFS over HTTP.  The is the umbrella JIRA for 
> the tasks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to