API Request/Response

From ePrize Developers Wiki

Revision as of 13:36, 2 March 2009 by Ken-fox (Talk | contribs)
Jump to: navigation, search

TODO: organize and explain.

The client must not assume the format of the canonical profile URL returned in the Location. Other API calls take the entire URL as a profile identifier, so deconstructing the URL is not necessary. A GET on the URL will fetch the full (safe) representation of the profile.

The {value} is part of the URL and must be encoded using standard URI encoding when the value contains reserved or non-ASCII characters. Values must be valid UTF-8 before being URI encoded. The server will decode the URI encoding, then decode the octet sequence as UTF-8. Arbitrary binary data is not allowed and may cause a 400 error.

The maximum length of {value} is 1000 octets after URI encoding.

This encoding requirement for {value} applies to all client provided portions of all ePrize Web Services URLs.

The order of keys in the response may change.

General rule: a canonical URL is a URL that does not redirect. Canonical URLs will be valid for as long as the {apikey} embedded in them is valid, however valid URLs may still produce error responses if the resource changes. The reason for preferring canonical URLs in some interfaces is the canonical URLs are not easily guessed.

XML media type

I'm going to mechanically convert the formats we've been using to XML with these rules:

foo: bar <foo>bar</foo>
foos: ["bar1", "bar2"] <foo>bar1</foo>

<foo>bar2</foo>

foo: [bar1: "baz1", bar2: "baz2"] <foo>

<bar1>baz1</bar1> <bar2>baz2</bar2> </foo>

Personal tools