Labs/Weave/ServerAPI: Difference between revisions

Jump to navigation Jump to search
Replaced content with "The contents of this page have been massively deprecated in favor of http://docs.services.mozilla.com/"
(Replaced content with "The contents of this page have been massively deprecated in favor of http://docs.services.mozilla.com/")
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
Back to [[Labs/Weave]].
The contents of this page have been massively deprecated in favor of http://docs.services.mozilla.com/
 
= Development Server API =
 
Currently, there is a RESTy API at https://services.mozilla.com/api/register/ that allows for remote account creation and password changes. Here is a brief description of how it works.
 
== General ==
 
Only two types of HTTP requests are made at any point in time, a GET or a POST.
 
The server will return as a response an appropriate HTTP status code and the body will contain a comma-seperated list of numbers, whose meaning is described a little later. Generally, the status code and the body value is what you have to preserve to inspect.
 
== Status Codes ==
 
'''400 Bad Request''' -- Will be returned if there was an error in the client's request. The numbers in the response body indicate what the errors were.
 
'''405 Method Not Allowed''' -- Trying to use GET where POST is to be used, and other such mismatches. No body.
 
'''201 Created''' -- Returned when an account as been successfully created. Body will contain a number to be interpreted as indicated in the table below.
 
'''417 Expectation Failed''' -- Returned when the client submitted all data correctly, except for the captcha elements. The response body will contain the HTML code required to display a new captcha.
 
'''200 OK''' -- Returned when the user's password was changed successfully. No body.
 
== Account Creation ==
 
In order to avoid automated registrations, we use a two step process and incorporate a captcha. First, you need to perform a GET request at https://services.mozilla.com/api/register/new/. This will return the HTML required to display a captcha to the user.
 
In the second step, you collect all the other information and make a POST request to the same address, with the following fields:
 
'''uid, password, mail, recaptcha_challenge_field, recaptcha_response_field'''
 
Of these, only 'mail' is optional. recaptcha_challenge_field and recaptcha_response_field are form fields that can be found in the HTML returned earlier.
 
Analyze the returned HTTP status code and body with the help of the table below and decide on the next course of action (Confirming to the user that the account was created, informing him that the username is already in use... etc.)
 
== Changing Password ==
 
This requires a single POST to https://services.mozilla.com/api/register/chpwd/ with the fields:
 
'''uid, password, new'''
 
HTTP 200 OK means the password was changed successfully. If you get a different status code, analyze the body with the help of the table below and decide on the next course of action.
 
== Checking if userID/email already exists ==
 
Sometimes you may want to check is a particular userID or email already exists asynchronously. This requires a single GET request to https://services.mozilla.com/api/register/check/USERNAME (Replacing "USERNAME" with desired username) or https://services.mozilla.com/api/register/chkmail/EMAIL (Replacing "EMAIL" with desired email address)
 
Analyze the returned HTTP status code and body with the help of the table below and decide on the next course of action.
 
== Body numeric codes and their meanings ==
 
<table border="1">
  <tr>
    <td>3</td>
    <td>Account created (but no email address specified)</td>
  </tr>
  <tr>
    <td>2</td>
    <td>Account created and verification email sent</td>
  </tr>
  <tr>
    <td>1</td>
    <td>The requested userID/email is available</td>
  </tr>
  <tr>
    <td>0</td>
    <td>The requested userID/email is already in use</td>
  </tr>
  <tr>
    <td>-1</td>
    <td>Client used a wrong HTTP method for the URL</td>
  </tr>
  <tr>
    <td>-2</td>
    <td>Missing uid field</td>
  </tr>
  <tr>
    <td>-3</td>
    <td>Invalid uid</td>
  </tr>
  <tr>
    <td>-4</td>
    <td>Invalid mail</td>
  </tr>
  <tr>
    <td>-5</td>
    <td>Account with given mail already exists</td>
  </tr>
  <tr>
    <td>-6</td>
    <td>Missing recaptcha_challenge_field</td>
  </tr>
  <tr>
    <td>-7</td>
    <td>Missing recaptcha_response_field</td>
  </tr>
  <tr>
    <td>-8</td>
    <td>Missing password field</td>
  </tr>
  <tr>
    <td>-9</td>
    <td>Internal server error</td>
  </tr>
  <tr>
    <td>-10</td>
    <td>Server quota exceeded</td>
  </tr>
  <tr>
    <td>-11</td>
    <td> Missing new field</td>
  </tr>
  <tr>
    <td>-12</td>
    <td>Incorrect password</td>
  </tr>
</table>
 
== The Sharing API ==
 
The sharing API allows the owning user of a folder to share it with other users, allowing them read-only access to it.  Simply make a POST request to https://sm-labs01.mozilla.org:81/api/share/ and provide the following parameters:
 
'''uid, password, cmd'''
 
<tt>uid</tt> and <tt>password</tt> are the username and password of the user making the share request.  <tt>cmd</tt> is a JSON object containing the following keys:
 
* <tt>version</tt> - This must be 1.
* <tt>directory</tt> - This is the directory to be shared, relative to the owner's user directory.
* <tt>share_to_users</tt> - This is a list of the users who should be given access to read the directory.  If it is a list with "all" as its only element, then the directory is readable by anyone.
 
If successful, the response will be HTTP 200 OK with a body text of "OK".  If the response code is different or the body is not "OK", then something has gone amiss.  (Unfortunately, the sharing API wasn't designed with nearly as much attention to detail as the rest of the API; this will be changed in a later release--see [https://bugzilla.mozilla.org/show_bug.cgi?id=443931 bug 443931].)
canmove, Confirmed users
1,173

edits

Navigation menu