Skip to content

API Docs

Jump to bottom Edit New page
Vincent Cardillo edited this page Jan 22, 2016 · 27 revisions

Preamble

We are moving away from hardcoding business logic into the app. Please rely on the backend APIs here to handle appState. If something is wrong in a certain case, then report the bug. Don't code around the mistake.

Init2 & Gatekeeper

GET /init2

The /init2 API call was created to keep backwards compatibility with existing users. You should use this call going forward, because it's more robust, and it includes the ability to include/exclude things depending on what you need. Init2 also can include the new /gatekeeper API for your bootup sequence.

Options are now appended as URL parameters, instead of the /arg1/arg2 structure. e.g.: /init2/arg1=foo&arg2=bar.

Possible URL parameters

  • copy=1|0: Whether or not to include copy. Defaults to 1.
  • date={date}: Same usage as existing init.
  • gatekeeper=1: Defaults to 0. If this is included, lat and long are also required in order for the gatekeeper API to execute (otherwise nothing will happen).

Examples

  • Same as /init: /init2
  • Same as /init/{date}: /init2?date=2015-10-22
  • Same as /init/{date}, but let's add the gatekeeper API in there too: /init2?date=2015-10-22&gatekeeper=1&lat=37.76637243960176&long=-122.41473197937012. Notice that you need gatekeeper=1
  • Perhaps you don't need the app copy on every init request. Set copy=0: /init2?date=2015-10-22&copy=0&gatekeeper=1&lat=37.76637243960176&long=-122.41473197937012

GET /gatekeeper/here/{lat}/{long}

Let's talk about this new big thing.

What to look at:

  • PRIMARILY: appState See possibilites here: Logic: appState Decision Tree. Use this flag to determine what state the app should be in, based on the user's location. The appState will handle every case properly, safely enough for you to adhere to it 100%. If something is wrong, then you must report the bug. Do not hardcode business logic into the app.

  • AvailableServices: What is currently "on", based on what's set in the admin. The only thing to really look at here is the OrderAhead object, which contains everything you need for building the OA menu, if available (it will be 99% of the time).

    • OrderAhead:
      • You'll need to pass kitchen and zone back to me when the user sends an OA order.
      • availableMenus is the mothership. That should have everything you need, and it's the same type of format that you've already been using. They're already sorted in the order that they should appear in the dropdown. Also, don't forget to look at the quantities of each item, per menu. So when the user selects "Feb 1 Lunch" versus "Feb 1 Dinner", those are different qty's.
        • Each menu has a Times array that tells you how to build the available times selection for a menu, and which are available. Later on "available" could be false, and that time should be marked as "sold out" IF false. Also, use the delivery_price associated with each time block to determine what to charge the customer for delivery.

  • appOnDemandWidget: Use to build the OD widget!

    • "selected": true|false: Whether or not it defaults to being selected. If false, select the first OA option.

      • IF selected is false, then menuPreview (below) will be populated for you to use with the "view menu" button.
      • ELSE, menuPreview will be NULL, and mealMode will be populated with the proper menu to use from the existing /menu/{date} API call (or from within /menu/{date} nested within the /init2 call).

    • "title" and "text": Obvious, hopefully.

    • "state": "open|sold out|closed". Same states as you get now. You don't really need to do anything with this. If the store is sold out, then I go and get the sold_out text, and I set it here as the text. So you don't have to do anything extra.

    • "menuPreview": null|{menuObj}. If the store is closed or sold out, then this will be populated with the menu object that you use to show the user the menu preview (this is equal to the "view menu" button that you would tap on the existing closed/soldout walls--I am just putting it here for ease).

OrderAhead with the /order API

Input

Simply add the following items to the root of the existing JSON. You're passing me back a few things from the Gatekeeper call.

  • "order_type": 2 (always set to 2 for order_ahead [see Appendix below])
  • "kitchen": AvailableServices->OrderAhead->kitchen
  • "OrderAheadZone": AvailableServices->OrderAhead->zone
  • "for_date": The for_date from whichever OA menu the order is from.
  • "scheduled_window_start": e.g.: "13:00"
  • "scheduled_window_end": e.g.: "14:00"
  • "MenuId": The menu_id from whichever OA menu the order is from.

Response

The response is the same as before, and hasn't changed. However, in the event of a 410 response (we're out of something), then the key /gatekeeper/here/{lat}/{long} is also added to the response, so that you may also update the OA inventory too. The /gatekeeper/here API is called with the same lat/long that you pass to the /order API initially.

/user API

GET /user/orderhistory

This returns an array of sections to display (In Progress, Delivered, etc.). Use the sectionTitle as the copy to display for the section heading. Each section has an array inside, named items. This is the list of items to display under this section. Display the title and price, like so:

bento-orders-2 2

Appendix

order_type

This can appear attached to an Order, or elsewhere.

  • 1: OnDemand
  • 2: OrderAhead
Add a custom footer
Add a custom sidebar
Clone this wiki locally