2
votes

Question

How do we make a resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?

Details

I have been searching for some time now about the proper way to build a RESTful API. Tons of great information out there. Now I am actually trying to apply this to my website and have run into a few snags.

What our site does:

  • Our site site allows people to play games and win prizes.

  • The API will allow developers to build their own games and use our backend to collect, validate, store user information and give out prizes.

Scenario:

Developers will create their game then make a call to our API to let the player play the game (play_game). This play_game method combines multiple functions that we do not want a developer to run independently.

Here is what a play_game call does on the server:

  1. It accepts player data the developer wants to store.
  2. Validates the data (compares it to rules setup in the control panel)
  3. Calculate what prize should be given.
  4. Returns what prize was won to the Developer.
  5. In addition there are multiple functions behind the scenes that get triggered like sending emails, etc.

Resource This is what our current resource looks like:

 http://site.com/api/play_game

Issue:

This doesn't hold to the idea of no verbs in RESTful API's.

How do we make this resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?

Notes:

After asking this question I have decided to use Phil Sturgeons RESTful Framework... unless someone has a better idea.

1
GET http://site.com/api/game seems fine to me. Or how about http://site.com/api/game/match Player data can be sent as query/cookie params or as some text in message body (XML, JSON, etc.. The response should also include all data relevant to the client. Sending emails and validation are alright, as well. Just remember that a GET request should always return the same response, unless the parameters change. Also, whenever you maintain a state of something on the server, make it available as a resource. Is this just a single request? Or is there constant interaction of client and server?toniedzwiedz
/game is currently a resource for getting data about a game, or updating settings for the game. I was under the impression that you would only go one uri deep. But if /game/match is RESTful then I think that would work fine. By maintain a state of something you mean, stored in the database or even semi stored data like a temporary session? This is a single request made multiple times by the same game. Each time you will get the same json structure but a different result since it is calculating a prize. Is that acceptable?zechdc
It doesn't matter how it's done internally but it should rather be permanent (the resource shouldn't disappear unless a DELETE request is issued). You can only store information server-side when it's available as a resource (has a URL that can be used by the client to request the information). I think dynamic resources are perfectly OK. For example GET http://example.com/random_number can return different values each time because the resource is just "a random number". Same goes with a prize in your case. You have a game that allows the user to win a random prize.toniedzwiedz
Check the answer of this question, it might help: stackoverflow.com/questions/2001773/…juanrossi

1 Answers

1
votes

You could place the following code into applications/routes.php

$route['(.*)'] = 'api';

Then you could access your API like: http://site.com/play_game

BUT

You'll only have access to ONE controller only (your api controller) Hope it helps