BaseMax / BaseMax/GooglePlayWebServiceAPI

Consistency in return values

オープン
#15 コメント 15 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
PHP
スター
42
フォーク
9
PR マージ指標
30日以内にマージされた PR はありません

説明

During my recent implementations and rewrites, I've introduced some "error reporting" to make it easier for the caller to figure if and what might have gone wrong. On error, several methods now return an array like

```php
[success:0, message:"reason"]
```

But not all of them – for example, most of the search/browse methods supposed to return a simple array of package names don't have this. There would be two options to reach (a sort of) consistency:

* returning `[success:0, message:reason]` instead (and if so, include `success:1` with a "good result) also for those methods that currently do not, moving the "real results" into a "sub-array" (which then, on error, could be empty or just not present at all)
* simply returning an empty array, and have a `getLastError()` method for obtaining the reason ***for all search/browse methods*** while keeping the current behavior for the others.

I'd prefer the first approach (so it's completely consistent) with the "empty real result". This combines the best of two worlds, e.g.

```php
$apps = $google->parseWhatever();
if ( empty($apps['data']) ) { // this could simply mean nothing found matching the criteria
if ( $apps['success'] ) { log('nothing found'); }
else { log ('ERROR occured: '.$apps['message']); }
} else { // do something with the data
```

I'd even go as far as to always include the `message` key, just leaving its value empty on success. That would make things most consistent.

What's your stance? If you agree, I'd go over the entire class another time and make it consistent:

* `success:0` only on *errors* – not generally on "no results" for a user-specified search (I vaguely remember I accidentally made it such in one case). `message` then holds the reason (e.g. the HTTP response, or parse error when an expected pattern didn't match, etc)
* `success:1` on success. `message` then is present but usually empty, but might eg hold a hint on why the result set is empty (like "no hits").

If we want to fix it, we want to do that as early as possible – before there are users whose code would otherwise break on some update.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

クラス全体を確認し、特に検索メソッドとブラウズメソッドについて、現在の戻り値を issue で説明されているエラー報告メソッドと比較してください。まず、1つのレスポンス契約について合意を得てください。完了とは、影響を受けるすべてのメソッドがその契約に一貫して従い、互換性に関する判断を未解決のまま残さないことを意味します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
php
領域
api, backend-api-design
issue の種類
リファクタリング
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
20/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。