Actions explained

There is many different actions used to create functionality for a client. This page tries to introduce all of them and group them in a way that developer can decide what to implement and what not.

Account actions

Critical

There is basic account actions, which can be used to login, register and modify accounts. To create an order and use some other actions, customer must log in. /account/login returns session_id, which then can be stored by client (for example to session for HTTP applications). Modify is not critical feature, but something customers really expects.

Customer actions

There is functionality to handle customer’s addresses. It can be used to set address of customer’s location, get all stored addresses and delete an address. Actual customer data does not have any address, so if client developer wants to ask an address in register form, it could be add separately using /customer/address/set. Then this address id can be passed to /restaurant/make_order instead of asking the address again from customer.


Optional

Favorite restaurants shared across all Fiidmi services can be accessed and handled with /customer/restaurants. There is support for listing all favorites, adding new one and deleting a favorite.


Optional

If there is need to calculate distance between restaurant and customer, action /customer/distance can be used for it. This takes restaurant id, which can be fetched for example with /restaurant/list or from favorite restaurants. If there is native support for doing this calculation, it should be preferred instead, as it will be faster at this moment. (we have little update planned for this, but it won’t be until far future it will be implemented)


There is possibility for accessing order history of customer. This information can be used to allow customer browse their past orders and that way maybe to reorder it by pressing a button. There is also gimmick related to cash payment (regular_cash) which requires customer to have done atleast one prepaid order beforehand to any restaurant. This action can be used to fetch past orders to check that conditions for creating cash order to such restaurant applies.


To implement bonus and PO-credit support to a client, this action is needed. /customer/information/bonus can be used to get customer’s available bonus to certain restaurant and /customer/information/po_credit to get total amount of PO-credit customer has.

Restaurant actions

Critical

/restaurant/list is used to get a list of restaurants by some criteria, like coordinates, address or name of restaurant. This information can then used to create a list of restaurants, which from customer can choose a restaurant, and then client can request actual restaurant data using /restaurant/get.


Critical

/restaurant/get is used to get actual restaurant’s data. There is few different ways for a customer to choose a restaurant. Main way is /restaurant/list and there is possibility to choose a restaurant from customer’s favorite restaurants.


Optional

/restaurant/ingredients and /restaurant/timetable can be used to access parts of restaurant data, the same data retrieved with /restaurant/get, for example to ease up HTTP based solutions.


Optional

There is support for rating restaurants and . There is few different fields, in addition to average. These ratings are same across every client in Fiidmi services. Ratings and reviews provides some means for customer to know which restaurant is better than other one.


Optional

If client wants to bring support for filtering restaurants by chain or just to be able to show if restaurant belongs to a chain, there is action /restaurant/chains for it. Some other actions, like /restaurant/list has chain_id attribute, which takes an id returned by this action and results to only restaurants from that chain to be shown.


Critical

After customer has selected a restaurant, added some products to cart (we do not provide cart implementation!) and is ready to create an order, this is the action to do it. This action uses specific construction to represent an order. It might be wise to use similar structure in internal cart implementation, so data would be easier to pass at this stage. This action may return errors in case there is some corner case client didn’t take in account, so it may be wise to take the errors returned by client and just show them to customer. There is some extra noise in the error though, specifically ORDER_VALIDATION_FAILURE, which may be good to filter out (there is no flag “internal” in the errors returned at this moment).


Optional

There is an action to show order status, but it is somewhat useless, as some restaurants uses some switches in wrong way, and some restaurants gets automatic receive. It may provide some nice value to customers though, to atleast see that the order has went through.

Service actions

Critical

According Finnish law, every service must have a service policy (Finnish: rekisteriseloste). This action can be used to show a service policy for Finnish and English language. Other languages can be added, please contact us if needed. If client stores some data from customers, we are not responsible of that data and client developer must ensure it adheres all aplied laws and conventions and our license agreement.

Optional

There is new action to get news of the service, and also flag to get restaurant specific news. Because I didn’t see any real reason to make separate action for restaurant specific news, these both uses this same action. This is maybe mostly useful for service level news, since rarely any restaurant write news. Some does, though. News also are in Finnish for time being.