PHPackages                             danack/artaxservicebuilder - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [HTTP & Networking](/categories/http)
4. /
5. danack/artaxservicebuilder

AbandonedLibrary[HTTP & Networking](/categories/http)

danack/artaxservicebuilder
==========================

0.4.1(10y ago)5136[6 issues](https://github.com/Danack/ArtaxServiceBuilder/issues)1PHP

Since Aug 4Pushed 10y ago3 watchersCompare

[ Source](https://github.com/Danack/ArtaxServiceBuilder)[ Packagist](https://packagist.org/packages/danack/artaxservicebuilder)[ RSS](/packages/danack-artaxservicebuilder/feed)WikiDiscussions master Synced today

READMEChangelogDependencies (6)Versions (12)Used By (1)

ArtaxApiBuilder
---------------

[](#artaxapibuilder)

Creates a library to consume an API from a Guzzle-like service description.

Why?
----

[](#why)

Writing a service to consume an HTTP API is not a fun task. Either there will be a lot of tedious boilerplate code that need to be written for each operation in the API, or you write the operations as generic methods that lose all type information.

Not only is writing the library in the first place not a fun task, but maintaining it when the HTTP API provider adds methods or subtly changes existing methods is also tedious.

Wouldn't it be nicer to be able to just define an operation like:

```
    "addUserEmails" => array(
        "uri" => "https://api.github.com/user/emails",
        'extends' => 'defaultOauthOperation',
        'summary' => 'Get users email addresses',
        'scopes' => [
            [\ArtaxApiBuilder\Service\Github::SCOPE_USER],
        ],
        'responseClass' => 'Github\Emails',
        'httpMethod' =>  'POST',
        'parameters' => array(
            'emails' => array(
                "location" => "json",
                "description" => "Array of the emails to add",
            ),
        ),
    ),

```

And then have all the service code generated and usable like this:

```
    $api = new GithubAPI(GITHUB_USER_AGENT);
    $emailCommand = $api->addUserEmails(
        $accessToken,
        [$newEmail1, $newEmail2]
    );

    $currentEmails = $emailCommand->execute();

    //The execute function has a docblock return type of
    //@return \Github\Emails
    foreach ($currentEmails as $email) {
        printf("Address %s verified %s primary %s ",
            $email->address,
            $email->verified,
            $email->primary
        );
    ]

```

Why not Guzzle service
----------------------

[](#why-not-guzzle-service)

- Underlying HTTP implementation in Curl/PHP streams isn't that great.
- Still a massive code base that doesn't really do that much.
- Untestable / unmockable.
- A service generated as code allows you to debug, extend or generally tart around with the code as necessary. Once the code is generated it's just there and completely modifiable (if you wish), rather than requiring everything being piped through Guzzle.
- Smaller memory requirement (and memory is PHP's Achilles heel) for using the generated service.
- Type-hinting all the things for Great Justice.
- Better exposure of underlying mechanisms. Although Guzzle is nice doing everything for you, having direct access to the request and/or responses is a pretty powerful technique for when people fuck up their API, and you need to hack around their stupidity (Github, I'm looking at you).

TODO
----

[](#todo)

- errorResponses - there is pretty much no error handling at the moment. This would be a good thing to be able to define at the API level rather than having to write code to support it.
- Unexpected responses as errors or exceptions - tbh this library is going to have to support both, as some cases exceptions are correct, and in others checking the response class type would be correct.
- filters - yep, going to need filters for variables in. Currently there is just a translate filter.
- includes - not the most vital thing in the world, but it would be nice to be able to split a service description up into manageable chunks.
- apiVersion - yep. Need some api versioning.
- Need to read rate limiting headers and make that information available through the api class.
- caching of responses + storing/using etags/last modified etc to avoid hitting rate limits early.

Not implemented
---------------

[](#not-implemented)

- additionalParameters - Having explicit parameters (`$foo->setBar($bar)`) is far better than having faith based parameters (`$foo->setParams(['bar' => $bar]);`) and so they aren't supported.
- responseModel - I haven't used this and don't particularly like the idea behind it, as there seem to be better (or at least looser coupled) ways of turning the responses into objects.
- responseBody - this is not necessary when you have control of the request.

Danack/Code vs Zend/Code
------------------------

[](#danackcode-vs-zendcode)

Please note, the fork Danack/Code is almost exactly the same as Zend/Code, except that it has some bug fixes which will only be released in the next major version of Zend/Code. As this won't happen for the foreseeable future, this library currently uses my fork with the fixes applied. The plan is to go back to the mainstream version of Zend/Code at the next major release..

###  Health Score

24

—

LowBetter than 31% of packages

Maintenance0

Infrequent updates — may be unmaintained

Popularity15

Limited adoption so far

Community10

Small or concentrated contributor base

Maturity60

Established project with proven stability

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~57 days

Recently: every ~125 days

Total

11

Last Release

3781d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/9db967c6005625e444a502fb830a30669b9fed53bfbc67e81a054508c0975a6b?d=identicon)[Danack](/maintainers/Danack)

---

Top Contributors

[![Danack](https://avatars.githubusercontent.com/u/1505719?v=4)](https://github.com/Danack "Danack (81 commits)")

###  Code Quality

TestsPHPUnit

### Embed Badge

![Health badge](/badges/danack-artaxservicebuilder/health.svg)

```
[![Health](https://phpackages.com/badges/danack-artaxservicebuilder/health.svg)](https://phpackages.com/packages/danack-artaxservicebuilder)
```

###  Alternatives

[php-http/cache-plugin

PSR-6 Cache plugin for HTTPlug

25126.1M82](/packages/php-http-cache-plugin)[illuminate/http

The Illuminate Http package.

11937.9M6.9k](/packages/illuminate-http)[rdkafka/rdkafka

A PHP extension for Kafka

2.2k24.3k1](/packages/rdkafka-rdkafka)[httpsoft/http-message

Strict and fast implementation of PSR-7 and PSR-17

87965.9k114](/packages/httpsoft-http-message)[mezzio/mezzio-router

Router subcomponent for Mezzio

265.4M90](/packages/mezzio-mezzio-router)[serpapi/google-search-results-php

Get Google, Bing, Baidu, Ebay, Yahoo, Yandex, Home depot, Naver, Apple, Duckduckgo, Youtube search results via SerpApi.com

69127.2k](/packages/serpapi-google-search-results-php)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)