Forum Discussion

kur83's avatar
kur83
Helper I
2 years ago
Solved

Should I use Power BI Rest API or Fabric Rest API?

I am in dilemma whether to keep on using Power BI rest API calls in updating Fabric workspace.    What's future of Power BI Rest API after launching of Fabric Rest API?
Need Help
  • Shravan133's avatar
    Shravan133
    2 years ago

    The Power BI REST API and the Microsoft Fabric REST API serve different purposes and are likely to coexist in various capacities. Here’s a brief overview to help with your decision:

    Power BI REST API

    • Current Use: It provides capabilities for managing Power BI resources, such as reports, dashboards, datasets, and workspaces. It allows for operations like embedding, user management, and refreshing datasets.
    • Future Outlook: While the Power BI REST API continues to be supported and updated, its focus remains on Power BI-specific functionalities. It is likely to receive updates relevant to Power BI’s features and improvements.

    Microsoft Fabric REST API

    • Introduction: Microsoft Fabric is designed to integrate various data services into a unified platform. The Fabric REST API is intended to offer broader capabilities that span across different Microsoft data and analytics services, including but not limited to Power BI.
    • Future Outlook: As Microsoft Fabric evolves, the Fabric REST API is expected to become more integral in managing and interacting with a broader suite of services beyond Power BI. This API aims to streamline operations across Microsoft's analytics and data platforms.

    Considerations for Your Decision

    1. Functionality: If your operations are heavily reliant on Power BI-specific features and integrations, the Power BI REST API might still be your best choice. If you’re looking for broader integration with Microsoft’s data ecosystem, exploring the Fabric REST API could be beneficial.

    2. Compatibility: Check if the Fabric REST API supports all the functionalities you currently use with the Power BI REST API. As Fabric API matures, it might offer new features or improved integrations that could make it more suitable for your needs.

    3. Future-Proofing: If you’re planning for long-term solutions and Fabric’s capabilities align with your future requirements, transitioning to the Fabric REST API might be a strategic move.

    4. Support and Updates: Stay informed about updates from Microsoft regarding both APIs to ensure you’re leveraging the best tools for your needs.

    Recommendations

    • Evaluate Needs: Determine if the Fabric REST API offers the necessary features and compatibility for your current and future needs.
    • Pilot Test: Consider running a pilot test with the Fabric REST API to assess its performance and suitability.
    • Stay Informed: Keep an eye on Microsoft’s announcements and documentation to stay updated on the latest developments and best practices.

    Ultimately, the choice depends on your specific requirements and how each API aligns with your long-term strategy.

reubwork's avatar
reubwork
Resolver I
1 year ago

Scratch that.
It works; 


We can develop in PBIP model locally, and publish a PBIP semantic model direct from source code using the SemanticModel endpoints; 
https://learn.microsoft.com/en-us/rest/api/fabric/semanticmodel/items/create-semantic-model?tabs=HTTP

 

The model needs to be compiled into a post body with inline base64 encoded elements.

https://learn.microsoft.com/en-us/rest/api/fabric/articles/item-management/definitions/semantic-model-definition

 

This opens up a fairly simple github flow development lifecycle. 

 

I'm using python; 

 

def get_pbip_deploy_body_payload(project_root, model_name, *args, **kwargs):

    semantic_model = os.path.join(project_root, f"{model_name}.SemanticModel")

    files = [
        "definition/database.tmdl",
        "definition/model.tmdl",
        "definition.pbism",
        "diagramLayout.json",
        ".platform",
    ]

    tables_path = f"{os.path.join(semantic_model,'definition', 'tables')}/*.tmdl"

    for file in glob.glob(tables_path):
        file_path = f"definition/tables/{os.path.basename(file)}"
        files.append(file_path)
    
    pp(files)

    body = {
        "displayName": model_name,
        "definition": {
            "parts":[]
        }
    }

    for file in files:

        with open(os.path.join(semantic_model, file), mode='rt') as file_data:

            text = file_data.read()
            
        inlineb64 = b64encode(text.encode('utf-8')).decode('utf-8')

        body["definition"]["parts"].append(
            {
                "path": file,
                "payload": inlineb64,
                "payloadType": "InlineBase64"
            }
        )

    return body

 

  • edevarhvide's avatar
    edevarhvide
    New Member
    1 year ago

    I am trying to solve the exact same problem now! I also get deployment of semantic models to work fine, but the crux is getting reports part right, since there are a whole load of files which are nested, and the API body's content then become very variable depending on the size of the PBIP folder.

     

    Have you had success with this? 

     

    Best regards

    • reubwork's avatar
      reubwork
      Resolver I
      1 year ago

      Hi there, 

      Sorry, no, I've not tried to deploy reports programmatically yet. I'm saving that for the future! 

      Actually I'm waiting for them to release the report definition as tmdl rather than json.

       

      Good luck though.