Designing Effective and Secure RESTful APIs: A Comprehensive Guide

In this presentation, we delve into the intricate process of creating RESTful APIs that not only meet the expectations of developers but also stand as reliable pillars for businesses in the long haul. APIs are an integral part of our daily online interactions, often unnoticed, fueling functionalities from social media interactions and weather updates to booking rides and beyond. They are the backbone of our modern digital experience. Let's embark on a detailed exploration with a focus on best practices for crafting APIs that developers find intuitive and businesses can depend on for stability and growth.

Tip: Opt for Clear, Logical Naming When naming entities within your API, clarity and logic should be your guides. Rather than obscure identifiers like "getCart123", choosing self-explanatory names such as "carts123" makes it evident that the API deals with a collection of items. Consistency in naming conventions and URL structures enhances the API's usability, making it straightforward for developers to understand and interact with.

Tip: Emphasize Reliability with Idempotent API Design Idempotency ensures that multiple requests have the same effect as a single one, crucial for preventing inconsistencies especially in the face of network retries. While GET and DELETE methods naturally align with idempotency, POST methods may require additional mechanisms, like client-generated unique IDs, to avoid unintended duplications. Understanding and implementing idempotency is vital for creating stable and reliable APIs.

Tip: Implement Versioning for Future-Proof APIs As your API evolves, versioning is key to introducing changes without disrupting existing integrations. Prefixing URLs with version numbers (e.g., /v1/carts123) allows for seamless transitions to newer versions, ensuring backward compatibility and giving developers the flexibility to update at their convenience.

Tip: Incorporate Pagination for Optimized Data Retrieval To manage data delivery efficiently, incorporating pagination is essential. It limits the volume of data returned in a single request, enhancing performance and user experience. Both page-offset and cursor-based pagination have their merits, with the choice depending on the specific requirements and data dynamics of your API.

Tip: Leverage Clear Query Strings for Effective Data Sorting and Filtering Utilizing query strings for sorting and filtering enriches the API's flexibility, allowing users to easily customize data retrieval. This approach not only makes the API more intuitive but also facilitates the addition of new criteria without impacting existing functionalities.

Tip: Prioritize Security from the Start Security should never be an afterthought in API design. Protect sensitive information by preferring HTTP headers for authentication over query parameters and ensuring all traffic is encrypted with TLS. Implement comprehensive access controls and stay informed on best security practices to safeguard your API.

Tip: Simplify Cross-Resource References Maintain simplicity in linking related resources within your API. Avoid complex query parameters by using straightforward paths, thereby making the relationships between resources clear and easy to navigate for developers.

Final Tip: Plan for Rate Limiting Implementing rate limiting is crucial for protecting your API from overload and abuse. Define sensible request quotas based on various criteria to ensure fair usage and protect against potential attacks. This not only secures your infrastructure but also promotes equitable access across all users.

By adhering to these guidelines and focusing on RESTful principles, you'll be well on your way to designing APIs that are not just functional but also secure, efficient, and a joy for developers to integrate.

Git Tip: Efficient File Staging with Interactive Mode

Ever found yourself with a heap of files in Git, pondering whether to add them individually or just bulk add everything with git add .? Here's a smarter approach: use Git's interactive mode.

Step-by-Step Guide:

1. Start with a Status Check: Begin by checking your repository status with git status. Imagine you're faced with 50 modifiable files.
2. Enter Interactive Mode: Instead of manually adding files one by one, initiate Git's interactive mode by running git add -i. This is especially handy when you have a specific subset of files to stage.
3. Select Files to Stage: Once in interactive mode, select the 'update' option by pressing 'u'. Now, you’re presented with the list of your modified files. To stage files, you have flexible options:
   • To add a single file, simply enter its corresponding number and hit enter.
   • For multiple files, type their numbers separated by spaces (e.g., '2 3') or a comma (e.g., '2,3').
   • To stage a range of files, use a dash (e.g., '1-3') to select files 1 to 3 inclusively.
4. Finalize the Staging: After making your selections, a subsequent git status will show all chosen files neatly staged and ready for commit. This method allows for precise control over what gets staged, streamlining the process significantly.

Revolutionizing JSON Validation with json_validate

Embarking on a journey through the extensive history of PHP, a language I've navigated for quite some time, crafting and revising thousands of lines of code. PHP, a stalwart language, is now set to unveil its latest iteration, version 8.3, slated for an official release by month-end. In this discourse, we delve into the pivotal modifications characterizing this upcoming release.

Revolutionizing JSON Validation with json_validate

The perennial question – is it JSON or not? Traditionally, one would resort to parsing the entirety using json_decode, awaiting confirmation of validity. Yet, the latest version introduces a game-changer: the json_validate function. This innovation promises the same accuracy but with significantly reduced resource consumption.

Streamlining Error Management in unserialize

The notorious unserialize() function, renowned for its erratic error generation from E_NOTICE to E_WARNING, is undergoing a paradigm shift in version 8.3. Expect consistent throws every time, eliminating the need to handle the nuances of E_NOTICE.

Unveiling the #[Override] Attribute

A valuable addition surfaces – the #[Override] attribute. Its primary utility lies in detecting methods that potentially override a counterpart in the parent class. Notably, it now triggers an error if the method in the parent class undergoes a name change, rendering the #Override-labeled method non-overriding.

Dynamic Connections to Class Constants

Prior to version 8.3, the loading of class constants remained a static or Reflection1-driven affair. With the advent of 8.3, a dynamic approach emerges, allowing the loading of these constants with variable interpolation.

Evolving Read-only Property Handling in the __clone() Process

In a prior release, PHP embraced the concept of declaring read-only properties during class instantiation. However, when it came to cloning, these properties faced constraints, limited to superficial duplication.

Version 8.3 dismantles these restrictions, enabling effective cloning of read-only properties within the context of the __clone() method. Beyond these pivotal updates, the PHP landscape undergoes additional shifts – the introduction of specific errors during DateInterval object initialization, such as DateMalformedIntervalStringException, enhancements to the mb_str_pad function, and notable performance boosts for array_sum() and array_product().

PHP 8.3 was released on November 23, 2023. It will be tested through three alpha releases, three beta, and six release candidates.

For a comprehensive overview of all the alterations, refer to php.net

Scopes

In Laravel filters or scopes, better said, can be used when you query a model with a specific method chain. We can start from the following example:

	Post::whereNotNull('published_at')->get();

This will take all the posts that are having the published_at column not null, or in simpler words all the posts that are active. With scopes this will look like this:

	class Post extends Model
	{
        /**
         * The attributes that should be cast to native types.
         *
         * @var array
         */
        protected $casts = [
            'published_at' => 'datetime',
        ];
	
        public function scopeActive($query)
        {
            return $query->whereNotNull('published_at');
        }
	}

The usage is like this:

	Post::active()->get();

The scopes can also accept parameters, as you may need to have a scope that accepts a date and then you can rename the scope like 'scopePublishedUntil' or 'scopePublishedBefore'. This can look like this:

    public function scopePublishedUntil($query, $param)
    {
        return $query->where('published_at', '<=', $param);
    }

You can use it like this:

	Post::publishedUntil('2021-11-09')->get();

Has/Is Methods

You can write the methods as you prefer, but keep in mind the basic thing: naming is the key! This is also the most dificult thing to do in programming. I recently encountered a huge bug in some code and that is the naming of so called 'boolean functions' or function that should only return a boolean. The simple rule is that what ever the method name, if it beggins with the words "is" or "has" then the return type must be a boolean. I will give a right example:

    public function isPublished(): bool
    {
        return $this->published_at !== null;
    }

This method will return 'true' or 'false' based on the condition inside. You must watch out for anything else then a boolean for the return type. once again the naming is the key!

source

PSR-2 or how to be a better developer

In the PHP world the entire community was not so compact in the early days when it comes to the coding standards. The idea of having a coding standard is so hard to adopt to some of us and it is causing more trouble in the thinking process.
This is so evident when doing code reviews for example and can cause different useless talks inside the development team.

Advantages

PHP Standard Requirements (PSR) is the the go to point for any kind of PHP developer. From my experience I can say that adopting a code standard like PSR-2 comes with multiple benefits. I will try to list them here:

- software maintenance; this is the main point and the most important one. If you do a search you can find that from the cost perspective between 40 and 80 percent of the lifetime cost of a software goes into maintenance and also the fact the hardly any software is maintained its whole life by the author.

- code quality; software development work involves reading a lot of code. Either writing code or code review involves reading the code and this should not be perceived as something difficult to do or more beautifully said, as something annoying.

- keep it simple; the complexity of a code structure is fighting against security in most cases. If you try to minimize the amount of code written during the project development you will also write less (hidden) bugs

- refactoring; when renaming a variable, renaming a method or breaking code in smaller parts it is called refactoring. When the code looks clean and ordered then the refactoring process goes easy and well.

- code language; every developer should know English. All the documentations regarding parts of some software are in English. The guy coding after you knows also English so for all of the reasons above the code language is connected with the software maintenance process and is bringing a plus to the readability of the code.

PSR-2 conventions

The PSR-2 conventions make a lot of sense for me at least in overall code improvement.

Indenting

I read a lot of articles with talks about what is better, tab or spaces. For PSR-2 things are simple in my perspective: “Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.”.

Properties

Developers know that naming variables is the hardest thing to do so thinks like “Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.” or like “Visibility MUST be declared on all properties.” are here to help.

Closures

“Closures MUST be declared with a space after the function keyword, and a space before and after the use keyword.” To check out all the conventions for the PSR-2 standard please visit this link

Tools

A great tool to have some automation in checking the code standards is PHP CodeSniffer. To install it you can do something like

	apt install php-codesniffer

or if you have PEAR installed

	pear install PHP_CodeSniffer

After installation you can use it from the console for example like this

	phpcs --standard=PSR2 src/

Or you can set up your IDE to automatically check the coding standard using the phpcs.

Go ahead and be a better PHP developer

A good developer should follow a code standard. I am standing up for PSR-2 here but what code standard you should use it is up to you. The important thing is to have one and follow it strictly.

If you are a business owner or project owner talk with your developers about coding standards.
If you are a developer adopt a coding standard.

source1 source2 source3

As a developer you encounter many ways of doing code, many ideas, some of them are nice and you are amazed on how nice and optimal is the implemented solution but some of them are really something that makes you wander about code and how a developer can write such a bad code.

Many times, this is covered in expressions like “ hey, it works” or “hey, we get the clients/money in, so all is ok”. Yes, this is 100% true but you need to understand, as a product owner or a business owner that this is what you call a medium product or even worse then this.

Recently, a customer provided his code to implement new features to me and I discovered a Laravel application with a SQL file :). Probably you have guessed … the migrations where not up to date with the database and the SQL file was the source of the “truth”.



If you wonder why or how can this be, it is very simple: life as a developer is like this; full of challenges. I remember when I was a junior developer I was scared of this situation and probably left the customer like this. With the time I learned to “own the mess”. This process is best described on the book “Clean Code” by Robert C. Martin (Uncle Bob).

Getting back to the customer, I was in the faze to tell him “hey this is crap, you need to pay more” or “hey, I am not doing this” because you can imagine that also in the rest of the code you can’t even think of something like PSR2. This is in my perspective the basic decent stuff a developer can at least do. Anyway, I “owned the mess” and carried on with my task. I looked on the SQL file, upgraded the hole migrations to a normal flow and moved on.



You may wonder why I did this? My answer is the I am not afraid of the “legacy code” or of the “spaghetti code”, I usually find real gems in this kind of code and as a result of my effort I implemented PHPUnit tests.

This is another topic on why you should at least try to get tests implemented in your project and if you have a new project just use TDD. I know it is super time consuming and very stressful, but the benefits on the long run are huge. The stability and the reliability of your software will be always there! If the tests are written is a good way and you test the code right, you are close to become a better developer then the majority.

Laravel requires some folders to be writable for the web server user. Using ACL

	// nginx = web server user
	// systemuser = your local/ssh user
	sudo setfacl -Rdm u:nginx:rwx,u:systemuser:rwx storage
	sudo setfacl -Rm u:nginx:rwx,u:systemuser:rwx storage

If you don't have ACL, you can use these but they're not so great;

	sudo chgrp -R www-data storage bootstrap/cache
	sudo chmod -R ug+rwx storage bootstrap/cache

source