Есть ли стандарт для соответствующих функций PHP?

В спокойном API для фруктов запрос предполагает что-то вроде этого:

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

Я думаю, что должен быть стандарт для функций, которые делают работу. Например, что-то может легко перевести на fruit.class.php,

fruit.class.php

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

Так что для моих приведенных выше примеров код будет выглядеть так:

  • 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'));

Существует ли такой отраслевой стандарт или функции API/ базы данных всегда в беспорядке? Я бы очень хотел стандартизировать свои функции.

Источник

4 ответа

Решение

Нет, стандарта нет, так как другие уже ответили... однако, в ответ на ваш вопрос о создании слишком большого количества методов... У меня обычно есть только один метод search(), который возвращает 1 или более результатов на основе моих критериев поиска, Я обычно создаю "поисковый объект", который содержит мои условия "где" в режиме ООП, который затем может быть проанализирован слоем данных... но это, вероятно, больше, чем вы хотите получить... многие люди строят свои DQL для своих слой данных и т. д. Есть много способов избежать getById, getByColor, getByTexture, getByColorAndTexture. Если вы начинаете видеть множество методов, охватывающих каждую возможную комбинацию поиска, вы, вероятно, делаете это неправильно.

Что касается именования остальных методов...ZF2 - это не ответ, но это тот, который я сейчас использую в своем проекте на работе, и его методы изложены примерно так (обратите внимание, это УЖАСНО, опасный код... открыть для SQL-инъекции... просто делаю это например):

// 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);

}
Источник

Вы говорите о получении фильтров. Я предпочитаю фильтры типа magento. Нет никакого соглашения о том, как должен выглядеть ваш внутренний код, и не так много фреймворков php поддерживают такую ​​функциональность, как получение фильтров из коробки. Вы можете посмотреть на реализацию magento rest api.

Вы можете использовать вызовы функций, такие как $model->get($where, $order, $limit), но вы должны

  • определить ресурсные свойства

  • сопоставить свойства ресурса с полями результата БД

  • определить, какие фильтры поддерживает ресурс

  • проверьте фильтры, удалите неподдерживаемые и создайте соответствующие $ where, $ order, $ limit

Источник

прелюдия

На самом деле не существует стандарта или соглашения о том, как должны выглядеть URL-адреса, которые охватывают (почти) все случаи.

Единственный стандарт, о котором я могу думать, - это HATEOAS (Hypermedia как движок состояния приложения), который в основном утверждает, что клиент должен получить URL-адреса, которые он может использовать из предыдущих запросов. Это означает, что то, что URL-адреса не очень важны (но как клиент может их обнаружить).

В наши дни REST - это шумиха, и часто не понимают, что это такое. Я предлагаю вам прочитать диссертацию Роя Филдинга " Архитектурные стили и проектирование сетевых программных архитектур", особенно главу 5.

Модель зрелости Ричардсона также хорошо читается.

PS: HAL (язык приложений гипертекста) является стандартом (среди прочих) для реализации HATEOAS.

Интерфейс

Поскольку не существует стандарта для URL, также нет стандарта для интерфейсов на эту тему. Это сильно зависит от ваших требований, вашего вкуса и, возможно, от того, на какой платформе вы создаете приложение.

Дэвид Садовски составил хороший список библиотек и фреймворков, которые могут помочь вам в разработке приложений RESTfull. Я предлагаю вам взглянуть на пару из них, чтобы посмотреть, решают ли и как они решают проблемы, с которыми вы сталкиваетесь. Вы должны быть в состоянии получить некоторые идеи от них.

Также прочитайте ссылки, которые я сделал в прелюдии, так как это даст вам хорошее представление о том, что можно и чего нельзя делать при создании реальных приложений RESTfull.

PS: извините за то, что не дал вам прямой окончательный ответ! (Я не думаю, что один действительно существует.)

Источник

Библиотека с открытым исходным кодом phprs может удовлетворить ваши потребности.

С phprs вы можете реализовать fruit.class следующим образом:

/**
 * @path("/api/fruit")
 */
class Fruit{
    /**
     * @route({"GET","/"})
     * @param({"color","$._GET.color"})
     * @param({"limit","$._GET.limit"})
     */
    function getFruits($color,$limit){
        return $oFruit->get(NULL, array('color' =>$color),$limit);
    }
    /**
     * @route({"GET","/*"})
     * @param({"id","$.path[2]"})
     */
    function getFruitById($id){
       return $oFruit->get($id);
    }
}
Источник
Другие вопросы по тегам