search

byu-osl / city-issue-tracker

An issue tracker for cities
GNU General Public License v2.0
2 stars 3 forks source link

URL scheme and API calls #4

Closed corbt closed 8 years ago

corbt commented 10 years ago

After the frontend meeting today we came up with a couple of points we'd like backend's input on. I'm opening the discussion.

  1. Since we're planning on building a one-page app, we're thinking about have all URLs of the form "[domain].com/#/...". This approach simplifies our task significantly while also imposing some tradeoffs. The good news is that this way no data ever has to be passed down with the HTML, eliminating the need for jinja2 templates. I think this is a good thing because it means that the frontend and backend can work almost entirely decoupled and as long as we both build to the Open311 spec, plus the (minimal) extensions we need to add to it, we won't have a problem. The bad news is that we lose most all googleability mojo this way.

  2. We need to define the set of extra-Open311 endpoints we'll need for our app to function. These will include at least

    • log-in,
    • log-out,
    • post an issue,
    • upload an image,
    • search and filter issues,
    • update an issue (admin only).

    I'll create a page on the wiki to organize these and reference it here.

  3. We need to extend the data stored with an issue to include at least an array of status updates. I'm not sure what the best way is to do this while remaining Open311-compliant but Sam said it's possible in the spec.

How does this look?

corbt commented 10 years ago

Ok, I've created a stub page on the wiki documenting the additional endpoints we'll need beyond the Open311 ones. I have 10 on the list right now (I thought of a few more after writing my previous message). Most should be pretty simple to implement on the server. Search might be the toughest.