-
Notifications
You must be signed in to change notification settings - Fork 0
Overview
Welcome to the App wiki! This wiki will host information about the REscour system architecture. Please visit the individual project repos for specific information about each project.
images/rescour-system-diagram.png The REscour system consists of a Back-End server application stack with a REST API (api.maasive.net), and a Front-End client application stack that includes the Website, Scraper, Workers, etc....
MaaSive.net supports the following verbs:
- GET
- POST
- PUT
- DELETE
An HTML request using GET receives a JSON dictionary object representing a collection or a resource in this format:
collection
http://api.maasive.net/<collection-name>/
{
collections : {},
resources : {},
filters : {}
}resource
http://api.maasive.net/<collection-name>/<resource-id>
{
attribute-1 : <string>,
attribute-2 : <int>,
attribute-3 : <dict>,
attribute-4 : <whatever-type>
}MaaSive.net does it automatically
URLs requesting a collection should always end in a '/', but the API will automatically redirect a client to the correct URL and add the slash. This behavior is important for bots (like google-bot) that try to crawl the API. The bot treats URLS that are identical except for the slash as two different pages, and the reputation is split between them.
URLS requesting a resource should not end in a '/', but the API will automatically redirect a client to the correct URL and remove the slash. Again this is important for search bots.
MaaSive.net does it automatically
Each of the dicts in the response object for a collection GET request exposes links for the client to continue navigating deeper into the API. These will do several things:
- Allow search bots to crawl the API - Bots don't see javascript, so it might be difficult for google-bot to crawl the Angular application.
- Allow future developers to traverse the API while developing their applications or maintaing existing ones. - If the API doesn't expose itself, documentation will have to be written for each and every request handler we build. With links, new devs can figure it out for themselves.
MaaSive.net does it automatically
Dict containing any sub-collections the client may want to navigate to, given the current context. This can be useful for defining "sub-handler" for collections that are different enough from their parent to warrant it.
collections : {
sub-collection-1 : http://foo.com/<current-path>/sub-collection-1/,
sub-collection-2 : http://foo.com/<current-path>/sub-collection-2/,
...
}Often we may want to continue to a sub-collection after several filters have been applied. Collection request handlers should allow for URI arguments that are not continuous, like this:
collections : {
...,
sub-collection-1 : http://foo.com/<filter-1>/sub-collection-1/<filter-2>/sub-collection-1a/<filter-3>/,
...
}MaaSive.net does it automatically
resources : {
resource-1 : http://foo.com/<current-path>/resource-1,
resource-2 : http://foo.com/<current-path>/resource-2,
...
}MaaSive.net does it automatically
In MaaSive.net we will define the filters as 'tags' with a behavior attached that affect the underlying collections and resources.
filters : {
filter-1 : http://foo.com/<current-path>/<filter-1>/,
filter-2 : http://foo.com/<current-path>/<filter-2>/,
...
}POST is used to add an item to a collection by making a POST html request to the collection.
http://api.maasive.net/<collection-name>/
This will be used to save a search to the database, or to que an email, etc...
PUT is used to update or insert an item into a collection. PUT requires the client to supply the ID and will either update the resource referenced by the ID or insert a new item into the collection with the specified ID.
http://api.maasive.net/<collection-name>/<resource-id>
DELETE will drop the specified resource from the specified collection if the reference is valid.
http://api.maasive.net/<collection-name>/<resource-id>