just entity.
TESTS ARE NOT UPDATED YET.
- Fix item_rest::get() to maintain the proper sort order, which
requires duplicating some Item_Model code.
- Elide "weight" from the REST version of item
- Adjust the weight of members according to the order they're returned
from the client. You can't add or remove members here, you can only
reorder them.
- Changed the wire protocol to handle more complex values.
Now "entity" and "members" are JSON encoded. The Gallery3
helper does this correctly.
- Changed the wire protocol for tag_item -- now it stores the
tag and item urls in the entity, not as members. This is more
consistent.
- Added missing security for renaming and deleting tags.
- Got rid of vestigial tag_rest::post(). We add/remove tags
via the relationship.
mostly issues around uninitialized variables, calling non-static
functions in a static context, calling Session functions directly
instead of on its singleton, passing non-variables by reference, and
subclasses not using the same interface as the parent class.
relationships. Now when you view a resource, it has 4 top level
elements:
url: the url of this resource
resource: array of key value pairs describing the resource
members: array of urls to members of this collection
relationships: array of array of members.
Relationships are a special type of collection that links two
different resources together. To remove a relationship, just
DELETE its url. To create a relationship, POST to its
collection.
Individual modules can add their own relationships to any
resource via a callback mechanism.
Example:
Array(
[url] => http://g3.com/rest/item/1
[resource] => Array (
[id] => 1
[album_cover_item_id] => 4
[captured] =>
[created] => 1264056417
[description] =>
[height] =>
...
)
[members] => Array(
[0] => http://g3.com/rest/item/2
[1] => http://g3.com/rest/item/3
[2] => http://g3.com/rest/item/4
[3] => http://g3.com/rest/item/5
...
)
[relationships] => Array(
[tags] => Array (
[0] => http://g3.com/rest/tag_item/2,1
[1] => http://g3.com/rest/tag_item/23,1
)
)
)
- Add support for retrieving a list of members from a collection
- Implement put(), post() and delete() for tags.
- Use tag_rest::delete() as a way to remove members from the tag collection
1) Deal in fully qualified URL resources through the rest
interface. All rest methods are now passed the complete url in
request->url.
2) Create rest::resolve() which lets individual resource definition
code convert a full url into the appropriate matching resource.
Implement gallery_rest::resolve() and tag_rest::resolve()
3) Reimplement tag_rest's get() and post() methods. They're much
simpler now.
4) Implement the tags_rest helper which supports working with the
entire tags collection.
1) Simplify gallery_rest to return flat models, no children and do no
validation for now.
2) Flatten the REST replies and use HTTP codes to indicate
success/failure instead of additional status messages.
3) Use the message and error code support in the base Exception class,
instead of brewing our own in Rest_Exception.
4) Get rid of rest::success() and rest::fail() -- we only need
rest::reply() since all failures are covered by throwing an
exception.
5) Get rid of /rest/access_key and just use /rest for authentication.
6) Inline and simplify rest::normalize_request since we only use it once
7) Change rest::set_active_user to succeed or throw an exception
8) Extract Rest_Exception::sendHeaders into rest::send_headers()
Here's what's currently broken:
1) Data validation. There currently is none
2) Logging. That's gone too
3) image block and tag code is broken
4) Tests are broken
5) No movie support
GET /tag?limit=nn,offset=nn Retrieve all tags sorted by count descending
GET /tag/uri/uri/uri Retrieve all the tags for the resource specified by path
GET /tag/t1/t2/t3 Retrieve all the items that have the specified tags
Can specifiy limit and offset to limit response size
types, and a subtype for specifics. Currently the top level bucket
collection, item, other
Here are the core subtypes so far:
collection: album, search, tag
item: movie, photo
other: login, reset, comment-fragment, comment
It's legal to create new page_subtypes whenever you want. Use the
appropriate page_type to get the coarse grain behavior that you want.
