Geoprocessing API: Create home for new endpoints

[arottersman]

• Determine...
  • where in the project the API should live
  • how it should interface with existing code
    - currently /apps/modeling houses all the the code we need to run the analyze and rwd tasks
    - Determine if it should remain there and have the new api depend on it, or if the relevent operations should be extracted into their own module for both apps to use
• Based on decisions above, add basic views for rwd and analyze tasks in the new geoprocessing-api app

[arottersman]

@mmcfarland and I met and discussed a plan of action:

Where should the API live?

• in its own geoprocessing-api django project

How should we reuse code?

A lot of ways to cut things, we talked about a few options:

• (a) We could rewrite views in geoprocessing-api, import from modeling and leave it mostly untouched
• (b) Matt pointed out there should only be one way to call up an analyze or RWD task, so we should move the relevant views into the geoprocessing-api.

We're going with (b). We'll save ourselves work if we ever have to change up the endpoints, and it's easier to keep a mental model of.

What about the calculations we do for analyze, constructing sql etc? Should modeling become a house for all modeling related code, or just a place for "stuff not in the api"?

• no clear better choice. We'll have to look at specifics for what should stay/go
• want to avoid circular dependencies
• don't want to duplicate task utils (these for the most part seem to already be in core)

Also

• We're going to build this work off of the collections API feature branch.