[Part of Sam's series on how to use the Ordr.in API]
Alright lets cut to the chase and go through the flow of placing a food order. I will try to be framework/language agnostic and just talk from a high level perspective. There are a few steps you need to follow in order to go through placing an order. The exact order (pun intended) of these steps is not set in stone. They can be switched around a bit, but this is a fairly typical way to do it. Lets get started using guest order as an example.
Gather address information: You need to gather all of the necessary information about the user's address to determine which restaurants can deliver to them. This can be hard coded or stored in environment variables if you are making something for yourself. You can also prompt the user if you are making a web/mobile/cli app.
Call the delivery list endpoint: This will give you all of the restaurants that are delivering to the user's address. For each restaurant, you now have important information such as the name ("na"), address ("ad"), expected delivery time ("del"), minimum order cost ("mino"), and cuisine types ("cu"). Cuisine types include categories like "Italian" or "Thai." That stuff is all important, but the thing you need to continue with order placement is the restaurant ID (“rid”). So have your user select a restaurant or pick a random one for all I care (it is your app after all!), and save the rid for the next API call.
Call the restaurant details endpoint: This gives you access to the nitty gritty details of what the restaurant has to offer. It gives you the location based details and the cuisine types again. What you really want from this, though, is the menu! For the scope of what we are doing here, this might as well be called the "menu" endpoint. Here you can display the menu to the user and build a tray based on their actions or use your own magic to design it for them. This is probably where you’ll spend the bulk of your development time either in a UI or in magic. If you need a recap on how to deal with menus, here you go. [link to menu 101]
Collect credit card info: This is something you also could have done when collecting the user's address info, but people are used to entering their credit card info at a some sort of "checkout" phase.
Call the fee endpoint: This is something you want to do so you can tell your users how much extra money they are being charged in whatever type of delivery fees exist for this restaurant. You’ll send the restaurant id, time (this usually defaults to ASAP), subtotal of their tray so far and delivery address.
Call the guest order endpoint and PLACE THE ORDER: Now the moment of truth has arrived! You can now take all of this information you have been gathering, and put it to use in one final, truly epic API call. And I mean epic! This one is a doozy to type out, and you will probably make some typos. Send the tray string along with the email, phone number, delivery address info, billing address info, credit card info, etc in the body of the post request (or the params object or regular function parameters depending on which API wrapper you are using), and an order will be placed! A confirmation will be sent to your user's email. Make sure you look through the response object to make sure no errors occured!
Debug what just broke: Your first (or second, or third...or more) order will not go through due to something you missed. You might have typed one of the field names incorrectly in the API call. Look at the error message, and try to gather any valuable information about what just went wrong. Go through the last few steps over again, and double check your code. Once that is fixed, it is time to fire up that post request. Lets get this party started!
Party like it's 1999!: Once your first guest order goes through on the test servers, and you are done thoroughly testing your app, get ready to place some real food orders! Order as much food as you can afford, and invite me over for a couple of beers to celebrate your awesome new hack!
If you don't feel like having to deal with all of that header setting nonsense of using REST APIs, you should check out our various API wrappers! I especially like the Swift API wrapper because I built it the day after the language was released, but that's another fun story.
Please check out the other 101 posts:
Dealing With The Menu
Test vs Production