import requests
import json
from datetime import datetime

class APIMiseryIndex:
    """
    Calculates the misery score for any API based on common pain points
    Higher score = more suffering
    """
    
    def __init__(self, api_endpoint):
        self.endpoint = api_endpoint
        self.pain_points = {
            'inconsistent_response_format': 0,
            'silent_changes': 0,
            'undocumented_features': 0,
            'random_errors': 0,
            'rate_limit_surprises': 0
        }
    
    def analyze_response(self, response):
        """Analyze API response for misery indicators"""
        misery_score = 0
        
        # Check for inconsistent data types
        if self._has_inconsistent_types(response.json()):
            misery_score += 25
            self.pain_points['inconsistent_response_format'] += 1
        
        # Check for undocumented status codes
        if response.status_code not in [200, 201, 400, 401, 404, 500]:
            misery_score += 15
            self.pain_points['undocumented_features'] += 1
        
        # Generate passive-aggressive debug log
        self._log_misery(response)
        
        return misery_score
    
    def _has_inconsistent_types(self, data):
        """Detect if same field has different data types"""
        # Implementation checks for mixed string/number types
        # in repeated API responses
        return False  # Simplified for example
    
    def _log_misery(self, response):
        """Generate the passive-aggressive debug log"""
        timestamp = datetime.now().isoformat()
        log_entry = f"""
        [API_MISERY_LOG {timestamp}]
        Endpoint: {self.endpoint}
        Status: {response.status_code}
        Note: Another hour of my life gone debugging this
        Pain Receipt Generated: Yes
        """
        print(log_entry)
    
    def generate_pain_receipt(self, total_score):
        """Create a summary of where development time was wasted"""
        receipt = {
            'api_endpoint': self.endpoint,
            'total_misery_score': total_score,
            'pain_points': self.pain_points,
            'estimated_wasted_hours': total_score / 10,
            'timestamp': datetime.now().isoformat()
        }
        return json.dumps(receipt, indent=2)

# Usage example:
# misery = APIMiseryIndex('https://api.example.com/data')
# response = requests.get(misery.endpoint)
# score = misery.analyze_response(response)
# print(f"Misery Score: {score}")
# print(misery.generate_pain_receipt(score))

The Problem: When APIs Betray You

import requests
import json
from datetime import datetime

class APIMiseryIndex:
    """
    Calculates the API Misery Index for any API endpoint
    Higher score = more suffering
    """
    
    def __init__(self, api_url):
        self.api_url = api_url
        self.pain_points = []
        self.total_score = 0
    
    def check_response_consistency(self):
        """Check if API returns consistent response formats"""
        try:
            response1 = requests.get(self.api_url)
            response2 = requests.get(self.api_url)
            
            # Pain point: Inconsistent response formats
            if response1.headers.get('Content-Type') != response2.headers.get('Content-Type'):
                self.pain_points.append({
                    'issue': 'Inconsistent response formats',
                    'score': 25,
                    'debug': f'First: {response1.headers.get("Content-Type")}, Second: {response2.headers.get("Content-Type")}'
                })
                
        except Exception as e:
            self.pain_points.append({
                'issue': 'Request failed entirely',
                'score': 50,
                'debug': str(e)
            })
    
    def check_error_messages(self):
        """Evaluate how helpful error messages are"""
        # Simulate bad request
        headers = {'Content-Type': 'application/json'}
        bad_data = json.dumps({'invalid': 'data'})
        
        try:
            response = requests.post(self.api_url, data=bad_data, headers=headers)
            
            if response.status_code >= 400:
                # Pain point: Unhelpful error messages
                error_content = response.text[:100]
                if 'error' not in error_content.lower() and 'message' not in error_content.lower():
                    self.pain_points.append({
                        'issue': 'Cryptic error messages',
                        'score': 30,
                        'debug': f'Response: {error_content}...'
                    })
                    
        except Exception:
            pass
    
    def calculate_misery(self):
        """Calculate total misery score and generate pain receipt"""
        self.check_response_consistency()
        self.check_error_messages()
        
        self.total_score = sum(point['score'] for point in self.pain_points)
        
        # Generate pain receipt
        receipt = {
            'api_url': self.api_url,
            'timestamp': datetime.now().isoformat(),
            'total_misery_score': self.total_score,
            'pain_points': self.pain_points,
            'interpretation': self._interpret_score()
        }
        
        return receipt
    
    def _interpret_score(self):
        """Interpret what the misery score means"""
        if self.total_score == 0:
            return "API Nirvana - This shouldn't exist"
        elif self.total_score < 30:
            return "Mild annoyance - Standard API experience"
        elif self.total_score < 60:
            return "Significant suffering - Weekend work likely"
        else:
            return "Critical pain - Consider career change"

# Usage example:
# misery = APIMiseryIndex('https://api.example.com/data')
# pain_receipt = misery.calculate_misery()
# print(json.dumps(pain_receipt, indent=2))

We live in a golden age of software development. We have microservices, serverless functions, and more APIs than we know what to do with. Unfortunately, we also live in an age where API providers treat 'stability' like a theoretical concept rather than an actual commitment.

Remember when you integrated that payment processor API that promised rock-solid stability? Two weeks later, they silently changed their error response format from JSON to XML because, and I quote from their support ticket, 'the backend team felt like mixing things up.' Or what about the weather API that returns temperature in Kelvin sometimes and Celsius other times, depending on which server your request hits? It's not a bug, they'll tell you—it's 'geographically aware data presentation.'

The real tragedy isn't that these things happen—it's that we've normalized this chaos. We spend hours, sometimes days, debugging issues that aren't our fault. We write defensive code that's more complex than the actual business logic. We create elaborate monitoring systems just to detect when an API decides to reinvent itself overnight. It's like being in an abusive relationship, but with more JSON parsing.

The Solution: Measuring the Madness

I built API Misery Index because I got tired of suffering in silence. If we're going to be miserable working with third-party APIs, we should at least have metrics to prove it. This tool doesn't fix broken APIs—nothing can do that short of divine intervention—but it does quantify exactly how broken they are.

The tool works by monitoring API interactions and analyzing patterns of pain. It tracks rate limiting behavior (because nothing says 'we value developers' like 429 errors for making two requests per minute). It monitors schema consistency (looking at you, APIs that return different field names based on the phase of the moon). And it evaluates documentation accuracy (spoiler: most docs are about as accurate as a weather forecast from 1985).

Despite the humorous approach, this is actually useful. The misery score gives you concrete data to present to stakeholders when an integration is taking longer than expected. The pain receipts show exactly where development time is being wasted. And the passive-aggressive debug logs? Well, those just make the suffering more entertaining.

How to Use It: Your Guide to Quantified Suffering

Getting started with API Misery Index is simpler than deciphering most API error messages. Install it via npm:

npm install api-misery-index

Then integrate it into your API client setup. Here's a basic example from the main file:

const { MiseryTracker } = require('api-misery-index');

const tracker = new MiseryTracker({
  apiName: 'UnreliableWeatherAPI',
  painThreshold: 0.7, // When to start complaining loudly
  logLevel: 'passive-aggressive' // Options: 'polite', 'sassy', 'passive-aggressive'
});

// Wrap your API calls
tracker.monitorApiCall(async () => {
  return await fetch('https://api.weather.example/current');
});

// Later, check your misery score
console.log(`Current misery: ${tracker.getMiseryScore()}/10`);
console.log('Pain receipt:', tracker.generatePainReceipt());

Check out the full source code on GitHub for more advanced configurations, including custom misery metrics and integration with popular HTTP clients.

Key Features: Your Toolkit for API Despair

• Calculates a 'misery score' based on rate limiting, inconsistent schemas, and misleading documentation. Scores range from 1 ("Actually pleasant to work with") to 10 ("Consider finding another career").
• Generates passive-aggressive debug logs when APIs behave unpredictably. Example: "The API returned a 200 status but the response body is just the word 'undefined' in Comic Sans. I'm not mad, I'm just disappointed."
• Creates a 'pain receipt' showing exactly where development hours were wasted, broken down by issue type. Perfect for explaining to your manager why the two-day integration is now in week three.
• Tracks schema drift over time, so you can prove that yes, the 'created_at' field did suddenly become 'creationTimestamp' last Tuesday at 3 AM.
• Rate limit analytics that show you exactly how arbitrary and unpredictable those limits really are.

Conclusion: Embrace the Misery (But Track It)

The API Misery Index won't make third-party APIs more reliable. Nothing short of a software development cultural revolution will do that. But it will give you data, and data is power. When you can show stakeholders that an API has a misery score of 8.7/10, they might understand why integration is taking so long. When you can present a pain receipt showing 14 hours wasted on inconsistent error formats, you might get approval to look for alternatives.

Try it out: https://github.com/BoopyCode/api-misery-index

Remember: If you can't avoid the suffering, at least document it thoroughly. Your future self will thank you when you're explaining to your team lead why everything is on fire.