{"id":417,"date":"2026-07-02T12:58:12","date_gmt":"2026-07-02T12:58:12","guid":{"rendered":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/?p=417"},"modified":"2026-07-02T13:05:09","modified_gmt":"2026-07-02T13:05:09","slug":"interface-segregation-principle","status":"publish","type":"post","link":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/2026\/07\/02\/interface-segregation-principle\/","title":{"rendered":"Interface Segregation Principle"},"content":{"rendered":"\n

Many Small Interfaces Instead of One Large Interface<\/h4>\n\n\n\n

The Interface Segregation Principle (ISP)<\/strong> states that no class should be forced to implement methods that it does not use.<\/p>\n\n\n\n

\n

\u201cClients should not be forced to depend upon interfaces that they do not use.\u201d \u2014 Robert C. Martin<\/p>\n<\/blockquote>\n\n\n\n

Simply put:<\/p>\n\n\n\n

Many small, specialized interfaces are better than one large, general-purpose interface.<\/strong><\/p>\n\n\n\n

If a class implementing an interface is forced to define methods that make no sense for it, that is a sign that the interface is too broad and violates ISP.<\/p>\n\n\n\n

Real-Life Example: How to Understand It?<\/h4>\n\n\n\n

Imagine you are a new employee signing an employment contract.<\/p>\n\n\n\n

Instead of receiving a standard software developer contract, HR hands you an agreement that requires you to:<\/p>\n\n\n\n

    \n
  • write code,<\/li>\n\n\n\n
  • clean the office,<\/li>\n\n\n\n
  • conduct workplace safety training,<\/li>\n\n\n\n
  • work at the reception desk,<\/li>\n\n\n\n
  • repair the photocopier.<\/li>\n<\/ul>\n\n\n\n

    Of course, you could sign it, but what about the responsibilities that have nothing to do with your role?<\/p>\n\n\n\n

    What would you do with the clause about repairing photocopiers if you’ve never even touched one?<\/p>\n\n\n\n

    You would somehow need to handle it, most likely by leaving it blank or writing:<\/p>\n\n\n\n

    \n

    “Not applicable.”<\/p>\n<\/blockquote>\n\n\n\n

    And that is exactly where the problem begins.<\/p>\n\n\n\n

    The contract says you are responsible for something even though you do not actually do it.<\/p>\n\n\n\n

    Programming works the same way.<\/p>\n\n\n\n

    When a class implements an interface, it commits to providing implementations for all of its methods. If the interface is too broad, the class must somehow deal with methods that do not apply to it\u2014typically by throwing an exception or leaving the method body empty.<\/p>\n\n\n\n

    That is an ISP violation.<\/p>\n\n\n\n

    Instead of one “contract for everything,” it is much better to have several specialized contracts:<\/p>\n\n\n\n

      \n
    • a contract for software developers (coding, code reviews),<\/li>\n\n\n\n
    • a contract for cleaning staff (cleaning and maintenance),<\/li>\n\n\n\n
    • a contract for receptionists (guest services and phone support).<\/li>\n<\/ul>\n\n\n\n

      Everyone signs only the contract that matches their actual responsibilities.<\/p>\n\n\n\n

      No sections are empty.<\/p>\n\n\n\n

      No obligations are fake.<\/p>\n\n\n\n

      A Thought Exercise<\/h5>\n\n\n\n

      Let’s imagine a human resources system.<\/p>\n\n\n\n

      What happens if we create one generic Employee<\/code> interface containing methods for every possible role?<\/p>\n\n\n\n

      Let’s look at the code.<\/p>\n\n\n\n

      Example \u2014 ISP Violation<\/h4>\n\n\n\n

      Suppose we are building a factory workforce management system.<\/p>\n\n\n\n

      The factory has three types of workers:<\/p>\n\n\n\n

        \n
      • a production worker who operates machinery,<\/li>\n\n\n\n
      • a manager who attends meetings and manages teams,<\/li>\n\n\n\n
      • an industrial robot that performs manufacturing tasks but neither eats nor takes breaks.<\/li>\n<\/ul>\n\n\n\n

        In the first approach, we create a single interface for everyone:<\/p>\n\n\n

        <\/pre>\n
        \/\/ One “big contract” for every worker in the factory<\/div>\n
        interface Employee {<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 \/\/ Every worker can work<\/div>\n
        \u00a0\u00a0\u00a0 void work();<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 \/\/ Every worker takes a lunch break<\/div>\n
        \u00a0\u00a0\u00a0 void takeLunchBreak();<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 \/\/ Every worker attends board meetings<\/div>\n
        \u00a0\u00a0\u00a0 void attendBoardMeeting();<\/div>\n
        }<\/div>\n\n\n
        Now let’s implement various worker types.<\/p>\n\n\n\n
        Production Worker<\/h5>\n\n\n
        <\/p>\n
        class ProductionWorker implements Employee {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void work() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(“I operate a machine on the factory floor.”);<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void takeLunchBreak() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(“I go to the cafeteria for lunch.”);<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void attendBoardMeeting() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Problem: production workers do not attend board meetings!<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 throw new UnsupportedOperationException(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Production workers do not attend board meetings!”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n

        <\/p>\n\n\n
        Industrial Robot<\/h5>\n\n\n
        <\/pre>\n
        class Robot implements Employee {<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void work() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(“I perform tasks on the assembly line.”);<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void takeLunchBreak() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Problem: robots do not eat!<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 throw new UnsupportedOperationException(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Robots do not need lunch breaks!”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/pre>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void attendBoardMeeting() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ Problem: robots do not attend meetings!<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 throw new UnsupportedOperationException(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “Robots do not attend meetings!”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        Manager<\/h4>\n\n\n
        <\/p>\n
        class Manager implements Employee {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void work() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I review reports and manage the team.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void takeLunchBreak() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I have lunch with a client.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void attendBoardMeeting() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I lead the quarterly board meeting.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        What’s Wrong with This Design?<\/h5>\n\n\n\n
        Classes Throw Exceptions for Unsupported Methods<\/strong><\/p>\n\n\n\n
        The Robot<\/code> class implements takeLunchBreak()<\/code>, but the only sensible thing it can do is throw an exception.<\/p>\n\n\n\n
        Anyone calling this method gets a runtime error instead of a compile-time indication that the operation is invalid.<\/p>\n\n\n\n
        The Interface Lies<\/strong><\/p>\n\n\n\n
        When somebody sees:<\/p>\n\n\n\n
        Robot implements Employee<\/p>\n\n\n\n
        they naturally assume that a robot can do everything an Employee<\/code> can do, including taking lunch breaks.<\/p>\n\n\n\n
        That assumption is false.<\/p>\n\n\n\n
        Changes Affect Everyone<\/h5>\n\n\n\n
        Suppose we add:<\/p>\n\n\n\n
        void signUnionAgreement();<\/p>\n\n\n\n
        to the Employee<\/code> interface.<\/p>\n\n\n\n
        Now every implementing class\u2014including Robot<\/code>\u2014must provide an implementation, even though robots will never sign any agreement.<\/p>\n\n\n\n
        Example \u2014 ISP-Compliant Design<\/h4>\n\n\n\n
        Let’s improve the design.<\/p>\n\n\n\n
        Instead of one large contract, we create several smaller interfaces, each describing a single capability.<\/p>\n\n\n\n
        Work Capability<\/h5>\n\n\n\n
        interface Workable {<\/div>\n
        \u00a0\u00a0\u00a0 void work();<\/div>\n
        }<\/div>\n\n\n
        Eating Capability<\/h5>\n\n\n
        <\/pre>\n
        interface Eatable {<\/div>\n
        \u00a0\u00a0\u00a0 void takeLunchBreak();<\/div>\n
        }<\/div>\n\n\n
        Management Capability<\/h5>\n\n\n
        <\/pre>\n
        interface Manageable {<\/div>\n
        \u00a0\u00a0\u00a0 void attendBoardMeeting();<\/div>\n
        }<\/div>\n\n\n
        Now each class implements only the interfaces that actually apply to it.<\/p>\n\n\n\n
        Production Worker<\/h5>\n\n\n
        <\/p>\n
        class ProductionWorker<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 implements Workable, Eatable {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void work() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I operate a machine on the factory floor.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void takeLunchBreak() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I go to the cafeteria for lunch.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        Robot<\/h5>\n\n\n\n
        class Robot implements Workable {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void work() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I perform tasks on the assembly line.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        Manager<\/h5>\n\n\n\n
        class Manager<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 implements Eatable, Manageable {<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void takeLunchBreak() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I have lunch with a client.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        \u00a0<\/p>\n
        \u00a0\u00a0\u00a0 @Override<\/div>\n
        \u00a0\u00a0\u00a0 public void attendBoardMeeting() {<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 “I lead the quarterly board meeting.”<\/div>\n
        \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 );<\/div>\n
        \u00a0\u00a0\u00a0 }<\/div>\n
        }<\/div>\n\n\n
        What Did We Improve?<\/h4>\n\n\n\n
        No More Unnecessary Exceptions<\/h5>\n\n\n\n
        The Robot<\/code> class does not have a takeLunchBreak()<\/code> method.<\/p>\n\n\n\n
        Nobody can call it accidentally.<\/p>\n\n\n\n
        The error is impossible because the method does not exist.<\/p>\n\n\n\n
        Interfaces Are Honest<\/h5>\n\n\n\n
        If a class implements Eatable<\/code>, it can actually eat.<\/p>\n\n\n\n
        If it implements Workable<\/code>, it can actually work.<\/p>\n\n\n\n
        The contract accurately reflects reality.<\/p>\n\n\n\n
        Changes Are Isolated<\/h5>\n\n\n\n
        Adding a new method to Manageable<\/code> affects only managers.<\/p>\n\n\n\n
        Robots and production workers remain untouched.<\/p>\n\n\n\n
        Composition Replaces a Monolith<\/h5>\n\n\n\n
        Classes can implement any combination of interfaces.<\/p>\n\n\n\n
        Just like in real life, a person may fulfill multiple roles at the same time.<\/p>\n\n\n\n
        Why Is ISP Important?<\/h4>\n\n\n\n
        Easier to Understand<\/h5>\n\n\n\n
        A small interface with one or two methods clearly communicates its purpose.<\/p>\n\n\n\n
        Seeing:<\/p>\n\n\n\n
        implements Eatable<\/p>\n\n\n\n
        immediately tells us what the class can do.<\/p>\n\n\n\n
        Changes Are Safe and Isolated<\/h5>\n\n\n\n
        When we extend Manageable<\/code>, only classes implementing that interface are affected.<\/p>\n\n\n\n
        Unrelated classes remain untouched.<\/p>\n\n\n\n
        Simpler Testing<\/h5>\n\n\n\n
        If a method depends on:<\/p>\n\n\n
        Workable<\/pre>\n\n\n
        we can create a very small mock implementation containing only a single method.<\/p>\n\n\n\n
        There is no need to implement ten unused methods.<\/p>\n\n\n\n
        Better Team Collaboration<\/h5>\n\n\n\n
        Narrow interfaces reduce merge conflicts.<\/p>\n\n\n\n
        Different developers can work independently on different interfaces without constantly interfering with one another.<\/p>\n\n\n\n
        Consequences of Ignoring ISP<\/h5>\n\n\n\n
        Imagine an interface with 30 methods implemented by 20 classes.<\/p>\n\n\n\n
        Adding a single new method forces modifications to all 20 classes\u2014even those that will never use it.<\/p>\n\n\n\n
        Developers often respond by adding:<\/p>\n\n\n\n
        throw new UnsupportedOperationException();<\/div>\n\n\n\n
        and moving on, creating traps for future team members.<\/p>\n\n\n\n
        When Should You Apply ISP?<\/h4>\n\n\n\n
        When Classes Leave Methods Empty or Throw Exceptions<\/h5>\n\n\n\n
        This is the strongest signal of an ISP violation.<\/p>\n\n\n\n
        The class is essentially saying:<\/p>\n\n\n\n
        \n
        “I have to implement this, but it makes no sense for me.”<\/p>\n<\/blockquote>\n\n\n\n
        When Interface Changes Affect Unrelated Classes<\/h5>\n\n\n\n
        If adding a method forces modifications in classes that will never use that method, the interface is too broad.<\/p>\n\n\n\n
        In APIs and Libraries<\/h5>\n\n\n\n
        Spring Framework is an excellent example of ISP.<\/p>\n\n\n\n
        Instead of one large repository interface, Spring Data provides specialized interfaces:<\/p>\n\n\n\n
          \n
        • CrudRepository<\/code><\/li>\n\n\n\n
        • PagingAndSortingRepository<\/code><\/li>\n\n\n\n
        • JpaRepository<\/code><\/li>\n<\/ul>\n\n\n\n
          Users choose only the level of functionality they actually need.<\/p>\n\n\n
          <\/p>\n
          \/\/ Minimal functionality<\/div>\n
          interface ProductRepository<\/div>\n
          \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 extends CrudRepository<Product, Long> {<\/div>\n
          }<\/div>\n\n
          <\/p>\n
          \/\/ Extended functionality if needed<\/div>\n
          interface ProductRepository<\/div>\n
          \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 extends JpaRepository<Product, Long> {<\/div>\n
          }<\/div>\n\n\n
          In E-Commerce Systems<\/h5>\n\n\n\n
          Instead of a single Payment<\/code> interface containing methods for cards, bank transfers, BLIK, and cryptocurrencies, it is better to create separate interfaces for each payment channel.<\/p>\n\n\n\n
          A BLIK implementation should not need to know anything about cryptocurrencies.<\/p>\n\n\n\n
          Memory Trick<\/h4>\n\n\n\n
          Just as a doctor signs a doctor’s contract, not an agreement that also requires repairing cars, each specialist should have a contract tailored to their responsibilities.<\/p>\n\n\n\n
          A well-designed interface describes one coherent capability<\/strong>.<\/p>\n\n\n\n
          As a result:<\/p>\n\n\n\n
            \n
          • classes remain honest about what they can do,<\/li>\n\n\n\n
          • contracts remain meaningful,<\/li>\n\n\n\n
          • code becomes more predictable,<\/li>\n\n\n\n
          • systems become easier and safer to extend.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
            Many Small Interfaces Instead of One Large Interface The Interface Segregation Principle (ISP) states that no class should be forced to implement methods that it does not use. \u201cClients should not be forced to depend upon interfaces that they do not use.\u201d \u2014 Robert C. Martin Simply put: Many small, specialized interfaces are better than […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"saved_in_kubio":false,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-417","post","type-post","status-publish","format-standard","hentry","category-solid"],"_links":{"self":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/comments?post=417"}],"version-history":[{"count":3,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/417\/revisions"}],"predecessor-version":[{"id":422,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/417\/revisions\/422"}],"wp:attachment":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/media?parent=417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/categories?post=417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/tags?post=417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}