Using tumblr API via php [closed]

Well, the above comment is mostly right. If this code was at least mostly operational and you wanted to know why something minor was causing an issue, I'm sure none of us would mind, but primarily this site is indeed for reviews only. SO, is for these kinds of questions. The only reason I'm putting an answer here is because I do think you need the review too. I don't know anything about that API to help you out specifically, but I can help you with your syntax.

You want to keep your code short to maintain legibility. So these long return lines, while nice to have on one line, are extremely difficult to read. Break them up into multiple lines. While not as "clean" looking, it is much easier to read.

$url = 'http://api.tumblr.com/v2/blog/';
$blogPath = self::$nameBlog . 'tumblr.com/info';
$key = '?api_key=' . self::$apikey;

$json = self::jsonGet( $url . $blogPath . $key );
return self::jsonToArray( $json );

If you find that you are repeating yourself, as with that URL, you can alleviate some of the repetition by making it a class property. This means you won't have to declare it in each method now, just use it, which also helps with legibility. In other words, in that example above, the $url declaration is now unnecessary, you will only need to access it in the $json variable, either with self:: as you have been doing (which means the below example should be static), or with this->.

public $url = 'http://api.tumblr.com/v2/blog/' . self::$nameBlog . '.tumblr.com/';

This might be more of a stylistic choice, but parenthesis around a condition, unless testing more than one condition, are unnecessary. However, if you are testing more than one condition, you should skip ternary operations all together as they begin to look cluttered.

//(!$json) == ! $json
return (!$json) ? self::throwException(__FUNCTION__, __LINE__) : $json;
//If PHP >= 5.3 you can do this
return $json ?: self::throwException(__FUNCTION__, __LINE__);

Instead of recreating a language construct, the exception, just use the one that already exists. Throw the exception in the class, then catch it during implementation. The only reason to create a custom "exception" is if you want to continue execution in that method afterwards, in which case you wouldn't call it an exception, you'd call it an error or warning.

Also, unless you are inheriting from this class and need to use those values specific to this class, rather than a shared one between parent and child, then use this-> instead of self::. They both work, but self:: explicitly says this information is static, thus the need for the static keyword. This limits inheritance quite a bit. This explanation may be a bit lacking, its from memory, so its the best I could do on short notice. I personally have never needed to use self:: in any of my code, nor static, so I haven't pursued it. The $errorContainer is a good example. This property can only be referenced by this class now. So any child classes will have to refer to the parent's $errorContainer instead of sharing it.

Finally, I hope you will eventually have a better destructor. print_r() and var_dump() are both debugging tools and should not be used in live environments. Instead, I would push the container to a log or an HTML file that would loop over it and produce a visually appealing error screen (as visually appealing as that can be), or both.