WDI Darth Vader

Project #3: RESTful API

Standups

James Tom Angie
Brad Bolander Eric Luczak Dylan Cairns
Isaac Bueno Myron Johnson Sonju Walker
Jim Haff Matt Herron Tim Rourke
Joe Greene David Hayes Kate Shirley
Chris Kim Tristan Marshall

Project #3: Building Your Own API

Overview

You’ve already worked in small groups to accomplish various labs and exercises, but this time we’re going to challenge you to work on a whole project by yourself!

Not only will you be asked to exercise additional creativity in designing your own project, your instructors will support you to architect, design, and build an API of your own design.

While your last project taught you how to get started with Ruby, SQL, & Sinatra, this project you'll be building something exciting with either Sinatra or Ruby on Rails! You'll also use Backbone.js for the client-side!

This is meant to push you both technically. It’s a lot harder to work on a full stack application using multiple frameworks, but that's most likely you’re going to find yourself doing in your first development job after WDI, and it's important to learn how to work with multiple moving parts.

Make it work, and make it awesome.


Technical Requirements

Your app must:

  • Use Ruby & Sinatra OR Rails to build an API.
  • Create a RESTful API using at least one model.
  • Include all major CRUD functions in a RESTful API that will work using CocoaREST, Postman, or any client of your choosing.
  • Consume your own API by making your front-end with HTML, Javascript, & jQuery, and Backbone.js.
  • Add support in your API for Backbone. Do not neglect support for standardized API access as well.
  • Add authentication to your API to restrict access to appropriate users. This can be done using API keys, user accounts, or any other form of authenication except OAuth (because we'll cover that soon).
  • Craft thoughtful user stories to explain your API.
  • Manage your source code using a standard Git flow on Github.
  • Layout and style your front-end with clean & well-formatted CSS and make it Responsive. Bootstrap, Skeleton, Foundation, and other front-end CSS frameworks are all welcome here!
  • Deploy your application online so it's publically accessible. For Sinatra, use Digital Ocean. For Rails, use Heroku.

Necessary Deliverables

  • A working API, hosted somewhere on the internet
  • A Backbone.js front-end that consumes your own API, hosted somewhere on the internet
  • A link to your hosted working app in the URL section of your Github repo
  • A git repository hosted on Github, with a link to your hosted project, and frequent commits dating back to the very beginning of the project
  • A readme.md file with:
    • Explanations of the technologies used
    • A couple paragraphs about the general approach you took
    • Installation instructions for any dependencies
    • Link to your user stories – who are your users, what do they want, and why?
    • Link to your wireframes – sketches of major views / interfaces in your application
    • Descriptions of any unsolved problems or major hurdles you had to overcome. You may not complete everything and that is okay. Tell us what you have left to do for version 2.0.

Suggested Ways to Get Started

  • Don’t hesitate to write throwaway code to solve short term problems.
  • Read the docs for whatever technologies / frameworks / API’s you use.
  • Write your code DRY and build your APIs RESTful.
  • Be consistent with your code style.
  • Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
  • Keep user stories small and well-defined, and remember – user stories focus on what a user needs, not what development tasks need accomplishing.
  • Write code another developer wouldn't have to ask you about. Do your naming conventions make sense? Would another developer be able to look at your app and understand what everything is?
  • Make it all well-formatted. Are you indenting, consistently? Can we find the start and end of every div, curly brace, etc?
  • Comment your code. Will someone understand what is going on in each block or function? Even if it's obvious, explaining the what & why means someone else can pick it up and get it.
  • Write pseudocode before you write actual code. Thinking through the logic of something helps.

Potential Project Ideas

For this project, we want you to build a creative product that you actually think someone will want to use. We won't have time to do tons of customer research, but take some time to brainstorm. If you're struggling for ideas, the ones below could help get you started.

Bucketli.st

Besides finishing WDI, you surely have one or two things you'd love to do with your life. Let's get 'em on paper! You could integrate with a third-party location-based API to allow users to search for a location or venue to add to their bucket list items.

Survey App

Imagine sending out a survey to everyone in the class – what should we eat for lunch today? Or 1-5, how well did you understand what we just learned? It would be even more awesome if it were realtime, so you could see answers pouring in as they're submitted.

Hello, Comments

Imagine the benefits of having an API where you could embed comments into any website you want. They could even update in realtime if you wanted, so that you'd never have to refresh the page. CMS providers across the world could quit writing code from scratch and just embed your widget instead.


Project Feedback + Evaluation

  • Project Workflow: Did you complete the user stories, wireframes, task tracking, and/or ERDs, as specified above? Did you use source control as expected for the phase of the program you’re in (detailed above)?

  • Technical Requirements: Did you deliver a project that met all the technical requirements? Given what the class has covered so far, did you build something that was reasonably complex?

  • Creativity: Did you added a personal spin or creative element into your project submission? Did you deliver something of value to the end user (not just a login button and an index page)?

  • Code Quality: Did you follow code style guidance and best practices covered in class, such as spacing, modularity, and semantic naming? Did you comment your code as your instructors as we have in class?

  • Problem Solving: Are you able to defend why you implemented your solution in a certain way? Can you demonstrated that you thought through alternative implementations?

  • Total: Your instructors will give you a total score on your project between:

    Score | Expectations ----- | ------------ 0 | Does not meet expectations. 1 | Meets expectactions, good job! 2 | Exceeds expectations, you wonderful creature, you!

    This will serve as a helpful overall gauge of whether you met the project goals, but the more important scores are the individual ones above, which can help you identify where to focus your efforts for the next project!