Is there a standard for corresponding restful PHP functions?

Question

In a restful API for fruit, the request assumes something like this:

api/fruit
api/fruit?limit=100
api/fruit/1
api/fruit?color=red

I think there must be a standard for functions that do the work. For instance, something may easily translate to fruit.class.php.

fruit.class.php

function get ($id, $params, $limit) {
    // query, etc.
}

So for my above examples, the code would look like

• api/fruit

  $fruit = $oFruit->get();
  

• api/fruit?limit=100

  $fruit = $oFruit->get(NULL, NULL, 100);
  

• api/fruit/1

  $fruit = $oFruit->get(1);
  

• api/fruit?color=red

  $fruit = $oFruit->get(NULL, array('color' => 'red'));
  

Is there an industry standard like this or are API/database functions always a mess? I’d really like to standardize my functions.

Answer 1

No, there is no standard as others have already answered...however, in answer to your issue about creating too many methods...I usually only have a single search() method that returns 1 or more results based on my search criteria. I usually create a "search object" that contains my where conditions in an OOP fashion that can then be parsed by the data layer...but that's probably more than you want to get into...many people would build their DQL for their data-layer, etc. There are a lot of ways to avoid getById, getByColor, getByTexture, getByColorAndTexture. If you start seeing lots of methods to cover every single possible combination of search, then you're probably doing it wrong.

As to rest method naming...ZF2 is not the answer, but it's the one I"m currently using on my project at work, and its methods are laid out like so (please note, this is HORRIBLE, dangerous code...open to SQL injection...just doing it for example):

// for GET URL: /api/fruit?color=red
public function getList() {
    $where = array();
    if( isset($_GET['color']) ) {
        $where[] = "color='{$_GET['color']}'";
    }
    if( isset($_GET['texture']) ) {
        $where[] = "texture='{$_GET['texture']}'";
    }
    return search( implode(' AND ',$where) );
}
// for GET URL: /api/fruit/3
public function get( $id ) {
    return getById( $id );
}
// for POST URL /api/fruit
public function create( $postArray ) {
    $fruit = new Fruit();
    $fruit->color = $postArray['color'];
    save($fruit);
}
// for PUT URL /api/fruit/3
public function update( $id, $putArray ) {
    $fruit = getById($id);
    $fruit->color = $putArray['color'];
    save($fruit);
}
// for DELETE /api/fruit/3
public function delete( $id ) {
    $fruit = getById($id);
    delete($fruit);

}

Answer 2

Prelude

There isn't really a standard or convention for how urls should look, that cover (nearly) all cases.

The only standard I can think of is HATEOAS (Hypermedia as the Engine of Application State), which basically states that a client should derive the url's it can use from previous requests. This means that what the urls are isn't really important (but how the client can discover them is).

REST is kind of a hype nowadays, and it's often not understood what it actually is. I suggest your read Roy Fielding's dissertation on Architectural Styles and the Design of Network-based Software Architectures, especially chapter 5.

Richardson Maturity Model is also a good read.

PS: HAL (Hypertext Application Language) is a standard (among others) for implementing HATEOAS.

Interface

Because there is no standard on urls, there is also no standard for interfaces on that subject. It highly depends on your requirements, your taste, and perhaps what framework you're building the application with.

David Sadowski has made a nice list of libraries and frameworks that can help you develop RESTfull applications. I suggest you take a look at a couple of them, to see if and how they solve the problems you encounter. You should be able to get some idea's from them.

Also read the references I made in the prelude, as it will give you good insight on do's and don'ts of building real RESTfull applications.

PS: Sorry for not giving you a straightforward definitive answer! (I don't think one really exists.)