{"id":2216,"date":"2018-11-14T05:14:22","date_gmt":"2018-11-14T05:14:22","guid":{"rendered":"https:\/\/www.migenius.com\/?p=2216"},"modified":"2020-11-02T21:29:10","modified_gmt":"2020-11-02T21:29:10","slug":"scopes-in-realityserver","status":"publish","type":"post","link":"https:\/\/www.migenius.com\/articles\/scopes-in-realityserver","title":{"rendered":"Scopes in RealityServer"},"content":{"rendered":"<p>A core concept in RealityServer which many new users have some difficulty understanding is <em>Scopes<\/em>. The use of scopes is critical in making effective use of RealityServer in a production environment where multiple users or multiple independent operations are happening at once. In this article we will go into more depth on what scopes are and how to use them.<\/p>\n<p><!--more--><\/p>\n<h3>Terminology<\/h3>\n<p>Before diving into scopes you really need to understand some of the terms we will use in relation to how data is stored and used in RealityServer. These terms are utilised throughout the documentation and it is important to have an understanding of what they mean. The main three you need to know are <em>Database<\/em>, <em>Elements<\/em> and <em>Attributes<\/em>.<\/p>\n<h4>Database<\/h4>\n<p>RealityServer includes a unique, in-memory database which holds all of the information that is loaded and used at any given time. Unlike a traditional database, this resides entirely in server memory and is not persisted to disk. You will not see the database referred to in the documentation often except for the C++ and Iray API since you rarely need to directly manipulate it when using RealityServer normally.<\/p>\n<p>It is difficult to stress just how unique RealityServer&#8217;s database system is and much of which relates to its handling of scopes. We are not currently aware of any other similar database for 3D applications which operates in this way and it is one of the reasons that adapting other renderers for deployment as a multi-user web service doesn&#8217;t really work. Once you&#8217;ve seen the power of scopes below it should become clear why this is needed.<\/p>\n<h4>Element<\/h4>\n<p>The RealityServer database stores <em>Elements<\/em>. An element is an instance of a specific type of data which RealityServer can use. You can always find all of the supported element types in the documentation for the <em>create_element<\/em> command. Some examples of common element types are:<\/p>\n<ul>\n<li>Camera<\/li>\n<li>Group<\/li>\n<li>Image<\/li>\n<li>Instance<\/li>\n<li>Light<\/li>\n<li>Material<\/li>\n<li>Options<\/li>\n<li>Polygon_mesh<\/li>\n<li>Texture<\/li>\n<li>Triangle_mesh<\/li>\n<\/ul>\n<p>There are additional types which are created and managed by RealityServer as well as some types which Iray supports that you can only access through the C++ API. However as you can see from the above list, these elements are the most common types of things you access in the course of using RealityServer.<\/p>\n<p>All elements in the database must have a name. When you use a command that wants the name of an element (e.g., <em>element_set_attribute<\/em>) as a parameter, this is the name used to find the element in the database.<\/p>\n<h4>Attribute<\/h4>\n<p>All elements in the database can additionally have <em>Attributes<\/em> associated with them. Attributes are named properties with values that you can store on a given element. There are many standard attributes which are recognised and used by Iray or RealityServer operations, however an attribute is completely generic and you can create your own to store whatever you need.<\/p>\n<p>Attributes are created on an element in the database using the <em>element_set_attribute<\/em> command and you can see a full list of the supported types in the documentaiton for that command. Basically elements are the things and attributes are the properties of those things.<\/p>\n<h4>Scopes<\/h4>\n<p>Chances are you are familiar with the concept of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Scope_(computer_science)\">scope<\/a> from programming, at least for things like variables. In RealityServer a scope defines a named container in which elements within the database live. Only elements and operations within that scope (or a more public scope) can see each other. All elements in the database have a scope (even if that is the global scope).<\/p>\n<h3>RealityServer and Scopes<\/h3>\n<p>So what do scopes give us and why do we want to use them? Basically anytime you want to share or restrict the sharing of data between multiple users or operations you will need to use scopes. This might be so different users can both navigate the same model but see different views, or creating shared scopes to cache data used by all users.<\/p>\n<h4>Creating and Using Scopes<\/h4>\n<p>Scopes are managed with a few simple commands. To create a new scope you use the <em>create_scope<\/em> command like this:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n{&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n    &quot;scope_name&quot; : &quot;Fancy_scope&quot;\n}, &quot;id&quot;: 1}\n<\/pre>\n<p>This creates a new scope under the global scope called <em>Fancy_scope<\/em>. You can also create child scopes (see the next section for full details), like this:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n{&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n    &quot;parent_scope&quot; : &quot;Fancy_scope&quot;,\n    &quot;scope_name&quot; : &quot;Child_of_fancy_scope&quot;\n}, &quot;id&quot;: 1}\n<\/pre>\n<p>You then use a given scope with the <em>use_scope<\/em> command. It doesn&#8217;t make any sense to do this as a single command since what it does is switch the scope to be used for subsequent commands in the same batch. So, typically it is used in a batch, like this:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;use_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;Child_of_fancy_scope&quot;\n    }, &quot;id&quot;: 1},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;import_scene&quot;, &quot;params&quot;: {\n        &quot;scene_name&quot; : &quot;Fancy_scene&quot;,\n        &quot;filename&quot; : &quot;scenes\/meyemII.mi&quot;\n    }, &quot;id&quot;: 2}\n]\n<\/pre>\n<p>This is a batch of two commands, the first switches the scope for the batch to <em>Child_of_fancy_scope<\/em> and then calls the <em>import_scene<\/em> command in that scope. The result is that all of the elements created by the import_scene command will be placed in the <em>Child_of_fancy_scope<\/em> scope.<\/p>\n<p>You can also switch scopes multiple times within a batch of commands. Calling <em>use_scope<\/em> each time can be tedious if you are using the same scope for the lifetime of your application so there are ways to automate this which we will see later.<\/p>\n<h4>Nesting Scopes<\/h4>\n<p>An important feature of scopes in RealityServer is that they can be nested. When you create a scope with the <em>create_scope<\/em> command you can specify the optional <em>parent_scope<\/em> parameter in order to nest the new scope under an existing scope. By default scopes are parented to the global scope. This nesting allows you to create scope structures like this.<\/p>\n<img class=\"aligncenter size-full wp-image-2140\" src=\"https:\/\/www.migenius.com\/migenius\/wp-content\/uploads\/2018\/11\/Nested-Scopes.svg\" alt=\"Nested Scopes\" \/>\n<p>This is a very common structure for a RealityServer application but certainly not the only possible one. The following JSON-RPC command sequence would create this structure.<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;Application Scope A&quot;\n    }, &quot;id&quot;: 1},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope A&quot;,\n        &quot;parent_scope&quot; : &quot;Application Scope A&quot;\n    }, &quot;id&quot;: 2},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope B&quot;,\n        &quot;parent_scope&quot; : &quot;Application Scope A&quot;\n    }, &quot;id&quot;: 3},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;Application Scope B&quot;\n    }, &quot;id&quot;: 4},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope C&quot;,\n        &quot;parent_scope&quot; : &quot;Application Scope B&quot;\n    }, &quot;id&quot;: 5},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope D&quot;,\n        &quot;parent_scope&quot; : &quot;Application Scope B&quot;\n    }, &quot;id&quot;: 6}\n]\n<\/pre>\n<p>Now when you call <em>use_scope<\/em> with a scope before executing your commands, those commands will have access to all of the elements within that scope and all of its parent scopes. Note that scope names must be globally unique, so you cannot have two scopes with the same name, even if they have different parents.<\/p>\n<p>Any new elements you create will go into the scope you are using. For example, in this case, if you call:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;use_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope D&quot;\n    }, &quot;id&quot;: 1},\n    ...\n]\n<\/pre>\n<p>Then the other commands in the batch will have access to all elements in <em>User Scope D<\/em>, <em>Application Scope B<\/em> and the global scope. However they will not see any elements in <em>Application Scope A<\/em> or <em>User Scope A\/B\/C<\/em>.<\/p>\n<p>These nested scopes effectively form a tree. The maximum depth of the scope tree is 255 (including the global scope). However we have never encountered an application that needed this amount. Most applications will only need between 2 &#8211; 4 levels.<\/p>\n<h4>Localization<\/h4>\n<p>So far we have just described scopes as a way of isolating elements from each other. However one of the most powerful features of scopes in RealityServer is localization. What this allows you to do is to make a copy of just a given element that exists in a scope your current scope has access to, within your current scope.<\/p>\n<p>Doesn&#8217;t sound so interesting at first. However consider this scenario. Let&#8217;s say you have a complex scene loaded, for example using 3GB of geometry, images, textures and other elements. Let&#8217;s load that into our application scope:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;Application Scope A&quot;\n    }, &quot;id&quot;: 1},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;use_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;Application Scope A&quot;\n    }, &quot;id&quot;: 2},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;import_scene&quot;, &quot;params&quot;: {\n        &quot;scene_name&quot; : &quot;Shared Scene A&quot;,\n        &quot;filename&quot; : &quot;scenes\/BigScene.mi&quot;\n    }, &quot;id&quot;: 3}\n]\n<\/pre>\n<p>Now you want to have two different users access this scene but you want each user to be able to have a different camera location and change the color of a material on an object in the scene. In a conventional system you would basically run two full copies of the data and consume the memory associated with that. Instead we can do this:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;create_scope&quot;, &quot;params&quot;: {\n        &quot;parent_scope&quot; : &quot;Application Scope A&quot;,\n        &quot;scope_name&quot; : &quot;User Scope A&quot;\n    }, &quot;id&quot;: 1},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;use_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope A&quot;\n    }, &quot;id&quot;: 2},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;localize_element&quot;, &quot;params&quot;: {\n        &quot;element_name&quot; : &quot;BigScene_camera_instance&quot;\n    }, &quot;id&quot;: 3},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;localize_element&quot;, &quot;params&quot;: {\n        &quot;element_name&quot; : &quot;Material_in_BigScene&quot;\n    }, &quot;id&quot;: 4}\n]\n<\/pre>\n<p>In RealityServer you can use <em>localize_element<\/em> to make a local copy of only the elements you wish to change into your scope. When you make your changes they then will not be visible to other scopes. Here we have made a new child scope and localized our elements to it.<\/p>\n<p>This means instead of duplicating 3GB of data in our example we can just duplicate the hundreds of bytes associated with the camera and material for each user. Then we can make changes in the usual in our user scope and only that user will see the changes:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\n[\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;use_scope&quot;, &quot;params&quot;: {\n        &quot;scope_name&quot; : &quot;User Scope A&quot;\n    }, &quot;id&quot;: 1},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;instance_set_world_to_obj&quot;, &quot;params&quot;: {\n        &quot;instance_name&quot; : &quot;BigScene_camera_instance&quot;,\n        &quot;transform&quot; : {\n            ...\n        }\n    }, &quot;id&quot;: 2},\n    {&quot;jsonrpc&quot;: &quot;2.0&quot;, &quot;method&quot;: &quot;mdl_set_argument&quot;, &quot;params&quot;: {\n        &quot;element_name&quot; : &quot;Material_in_BigScene&quot;,\n        &quot;argument_name&quot; : &quot;diffuse_color&quot;,\n        &quot;value&quot; : { &quot;r&quot;: 1.0, &quot;g&quot;: 0.0, &quot;b&quot;: 0.0}\n    }, &quot;id&quot;: 3}\n]\n<\/pre>\n<p>Localization is perhaps the most important aspect to understand and use. If you do not localize elements to a more private scope before changing them, then all users may see the changes.<\/p>\n<h3>Best Practice<\/h3>\n<p>For most applications, you will want at least two levels of scope. An <em>application scope<\/em> which holds all data which is not specific to a given user and a <em>user scope<\/em> which holds any data which a specific user can modify.<\/p>\n<p>If you have models, textures and other data that are always shared and you want to keep them loaded all the time, then import or create them in the application scope.<\/p>\n<p>As soon as you want to change an element for a given user, create and use a user scope and then localize that element by calling the <em>localize_element<\/em> command on that element.<\/p>\n<p>Typically you will create a new user scope whenever a user navigates to your application. Since they need to be unique we usually named them with a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Universally_unique_identifier\">UUID<\/a> or long random string.<\/p>\n<p>The above strategy is used by the <em>Simple JavaScript Render Loop Rendering Sample<\/em> that ships with RealityServer if you want to see it in action. Of course you may have different use cases where another structure is appropriate. A common one may be creating view scopes under the user scope if an application has multiple views of the same model.<\/p>\n<p>Finally, note that the rendering commands, render loop and other rendering functionality are all scope aware. So they will render the version of the scene defined by the scope you are in.<\/p>\n<h3>Automating Scope Usage<\/h3>\n<p>You can see that scopes are extremely useful and you will want to be using them in almost every RealityServer application. However it can also become repetitive to send a <em>use_scope<\/em> command for every set of commands you want to run. If you forget it can also be difficult to debug the issue as you will find your commands can&#8217;t access elements you created inside scopes (since the command is running in the global scope). RealityServer has several features to help.<\/p>\n<h4>JavaScript Client Library StateData<\/h4>\n<p>If you are using the JavaScript Client Library in your application (this is used by the examples that ship with RealityServer), then you can set custom <em>StateData<\/em> which will apply a specific command to each set of requests. You can apply this globally to the RSService object which will use it for all requests, like this:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nconst service = new com.mi.rs.RSService(&#039;127.0.0.1&#039;, 8080);\n\n\/* ... *\/\n\nlet state_data = new com.mi.rs.StateData(null, null, [\n    new com.mi.rs.Command(&quot;use_scope&quot;, {scope_name:&#039;Fancy_scope&#039;})\n]);\nservice.defaultStateData = state_data;\n<\/pre>\n<p>Or you can also define it on a <em>CommandSequence<\/em> to just apply there. See the JavaScript Client Library documentation for <em>com.mi.rs.StateData<\/em> for full details.<\/p>\n<h4>Auto Scope Plugin<\/h4>\n<p>This plugin comes with the RealityServer Extras plugins set and allows you to control scope through HTTP headers instead of explicitly writing out a <em>use_scope<\/em> command each time. It is a state handler plugin that automatically uses a specified scope for a request and if the scope does not exist it creates it, so you don&#8217;t have to use <em>create_scope<\/em> either (unless you are making child scopes). You can simply set a HTTP header and if present it will generate and use the scopes. Configure as follows in your <em>realityserver.conf<\/em> file after installing the plugin:<\/p>\n<pre class=\"brush: plain; title: ; notranslate\" title=\"\">\n&lt;url .*&gt;\nstate auto_scope\n&lt;\/url&gt;\n\n&lt;user auto_scope&gt;\nheader rs-scope\n&lt;\/user&gt;\n<\/pre>\n<p>RealityServer will then look for the HTTP header <em>rs-scope<\/em> and if found will use it to set the current scope for commands or create it if it doesn&#8217;t exist. To use this you will naturally need to be using a client that allows you to control the headers of your request (most clients should allow this).<\/p>\n<h3>Scopes in Server-side V8 Commands<\/h3>\n<p>Custom V8 commands on the server-side will execute in the scope they are called in. So if you call one in a batch that has a <em>use_scope<\/em> call before it, then the V8 command will run in that scope. However you can also call scope commands from within V8 to change the scope during execution. For example:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nRS.use_scope({ scope_name: &#039;Fancy_scope&#039; });\n<\/pre>\n<p>Two other scope commands not discussed yet can also be very useful in V8, namely <em>get_scope<\/em> which returns the name of the current scope and <em>scope_exists<\/em> which checks if a scope of a given name already exists. Here is a quick example of how that might be useful in V8:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nlet original_scope = null;\nif (RS.scope_exists({ scope_name: &#039;Fancy_scope&#039; })) {\n    original_scope = RS.get_scope();\n    RS.use_scope({ scope_name: &#039;Fancy_scope&#039; });\n} else {\n    throw new RS.Error(RS.Error.INVALID_PARAMETERS,\n        &#039;Fancy_scope does not exist&#039;);\n}\n\n\/* .. *\/\n\nRS.use_scope({ scope_name: original_scope });\n<\/pre>\n<p>This checks if a required scope exists and if it does uses it but first stores the name of the current scope so it can be restored later on. In general a V8 command should always restore the scope it had when it started to avoid unexpected side-effects for the user.<\/p>\n<p>If you are using RealityServer 5.2 build 2272.287 or later then you have access to the new <em>Scope<\/em> class which makes this process even simpler in V8. Using this class the above code would become:<\/p>\n<pre class=\"brush: jscript; title: ; notranslate\" title=\"\">\nconst Scope = require(&#039;Scope&#039;);\n\n\/* ... *\/\n\n    let original_scope = Scope.current();\n    let new_scope = new Scope(&#039;Fancy_scope&#039;);\n    if (new_scope.exists) {\n        new_scope.use();\n    } else {\n        throw new RS.Error(RS.Error.INVALID_PARAMETERS,\n            &#039;Fancy_scope does not exist&#039;);\n    }\n\n\/* ... *\/\n\n    original_scope.use();\n<\/pre>\n<p>Please refer to the Server-side V8 documentation for full details. We definitely recommend using the <em>Scope<\/em> class instead of directly calling the related commands.<\/p>\n<h3>The Admin Console<\/h3>\n<p>There is some information about the RealityServer database which is not possible to obtain through the API. For example a list of all of the elements in the database, or all of the currently defined scopes. This data can however be obtained through the Admin Console.<\/p>\n<img class=\"aligncenter size-full wp-image-2140\" src=\"https:\/\/www.migenius.com\/migenius\/wp-content\/uploads\/2018\/11\/admin_console.jpg\" alt=\"Admin Console\" \/>\n<p>By default this can be accessed in your browser by navigating to port 8081 on your server (unless you have changed the configuration). It is a very barebones diagnostic tool but does allow you to see all of the currently defined scopes and all of the elements in the database.<\/p>\n<p>This tool can be extremely helpful when diagnosing scoping issues or just finding out what RealityServer currently has in its database.<\/p>\n<h3>Dry But Useful<\/h3>\n<p>Just like our <a href=\"https:\/\/www.migenius.com\/articles\/managing-user-sessions-with-uac-in-realityserver\">last post on UAC<\/a>, scopes are a pretty dry topic but critical for success with RealityServer. Hopefully this gives you a better understanding of what they are and how to apply them, but of course please <a href=\"https:\/\/www.migenius.com\/contact\">contact us<\/a> if you&#8217;d like to learn more.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A core concept in RealityServer which many new users have some difficulty understanding is Scopes. The use of scopes is critical in making effective use of RealityServer in a production environment where multiple users or multiple independent operations are happening at once. In this article we will go into more depth on what scopes are [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":2218,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"spay_email":"","jetpack_publicize_message":"Scopes in RealityServer and why they matter","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[15,30],"tags":[14,27],"jetpack_featured_media_url":"https:\/\/www.migenius.com\/migenius\/wp-content\/uploads\/2018\/11\/scopes_feature.jpg","_links":{"self":[{"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/posts\/2216"}],"collection":[{"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/comments?post=2216"}],"version-history":[{"count":9,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/posts\/2216\/revisions"}],"predecessor-version":[{"id":2445,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/posts\/2216\/revisions\/2445"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/media\/2218"}],"wp:attachment":[{"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/media?parent=2216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/categories?post=2216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.migenius.com\/wp-json\/wp\/v2\/tags?post=2216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}