rephrase sentences in development-guide.md file

    - [Client SDK](#client-sdk)

  - [Development of Emulation Logic](#development-of-emulation-logic)

    - [Server-side](#server-side)

    - [Server-side (multiple APIs)](#server-side-multiple-apis)

    - [Server-side (For multiple APIs)](#server-side-for-multiple-apis)

    - [Client-side](#client-side)

      - [Code organization](#code-organization)

  - [Unit tests for the new micro-service](#unit-tests-for-the-new-micro-service)

            \____ <mec-identifier>.go

```

### Server-side (multiple APIs)

### Server-side (For multiple APIs)

After the server stubs have been generated for each APIs separately (see [server stubs](#server-stubs)), the folder structure for single API will be something like the structure shown below:

```

There may be multiple files for `api_<api_tag_i>` and `model_<model_name>` depending on the tags and component schemas in the OAS file used to generate the server stubs.

> Note: _i_ in _api_tag_i_ used to indicate any signle API.

Steps to implement server side emulation logic for multiple APIs:

1. **Creating new folder structure**

2. **Copying _API_ Folder**

   According to the multiple APIs folder structure, `swagger.yaml` file present under `api` folder of each single API is added in their corresponding `api/<api_tag_i>` sub-folder for  multiple APIs scenario.

   From the generated server stubs for each API, copy the `api/swagger.yaml` file to the corresponding `api/<api_tag_i>` sub-folder for multiple APIs scenario.

3. **Copying _Go_ Folder**

    According to the multiple APIs folder structue, sub-folders are added with specific `<api-tag_i>` name under `server` folder for each API. Now copy `api_<api_tag_i>.go`, `api_unsupported.go`, `model_<model_name>.go` and `README.md` files from `go` folder of each single API folder structure to its specific `<api-tag_i>` folder for multiple APIs scenario. 

   For multiple APIs scenario, create sub-folders with specific `<api-tag_i>` name under `server` folder for each API. Then copy `api_<api_tag_i>.go`, `api_unsupported.go` (if any), `model_<model_name>.go` and `README.md` files from each API `go` folder to its specific `<api-tag_i>` folder.

4. **Modify _main.go_**

   Remove the code in _main.go_ file of multiple API folder structue and add the following function(s) to it:

   - _main()_: This will be the main function which calls the other functions to initialize the service

   For multiple API scenario, there should be a single _main.go_ file to initialize all the corresponding APIs for a particular service. The following changes should be done in _main.go_ file:

   - _main()_: main function to call the other functions to initialize the service

      - Add an anonymous function inside the _main()_ function which will initialize the service

      - Add another anonymous function inside the _main()_ function which will initialize the metrics endpoint

5. **Copy and Modifying Routers**

   Firstly, copy the `router.go` file of any single API folder structure to `router.go` of multiple API folder structue. Then keep on adding the routes in `route` array structure from `router.go` file of other APIs in this file.

   There should be a single _routers.go_ file under _server_ folder in case of multiple APIs. From the generated server stubs, copy `router.go` file from a single API and paste it in the `server/routers.go` file. Now copy the routes defined in rest of the APIs in the same `server/routers.go` file.

   Now, in the `server/routers.go` file, make the following changes:

6. **Create the service handler file**

   Create a `server/<mec-identifier>.go` and `server/<api_tag_i>/<api_tag_i>.go` files. This `server/<mec-identifier>.go` file will contain all the common handler functions for endpoints and the emulation logic for the service while `server/<api_tag_i>/<api_tag_i>.go` will contain all the handler functions for endpoints and the emulation logic for the specific service APIs

   Create `server/<mec-identifier>.go` and `server/<api_tag_i>/<api_tag_i>.go` files. The `server/<mec-identifier>.go` file will contain all the common handler functions for endpoints and the emulation logic for all the APIs in that service. And `server/<api_tag_i>/<api_tag_i>.go` file will contain all the handler functions for endpoints and the emulation logic for that specific service API.

7. **Implement handler function for unsupported endpoints**

   In the `server/<api_tag_i>/api_unsupported.go` file (if it exists), for each of the handler functions, replace the previous code with `notImplemented(w, r)` and add this function in the `server/<mec-identifier>.go` as follows:

   In the `server/<api_tag_i>/api_unsupported.go` file (if exists), for each of the handler functions, replace the previous code with `notImplemented(w, r)` and add this function in the `server/<mec-identifier>.go` as follows:

   ```go

   func notImplemented(w http.ResponseWriter, r *http.Request) {

   Remove the previous code in each of the `server/<api_tag_i>/api_<api_tag_i>.go` file and replace it with a handler function. Implement all those handler functions in the `server/<mec-identifier>.go` file.

9. **Implement SBI Communication Logic**

9. **Implement SBI Communication Logic (If required)**

   The new MEC service will need to communicate with other AdvantEDGE/Sandbox services to, for example, get updated scenario information via South Bound Interface (SBI). To do this, create a `server/sbi` folder and create a `<mec-identifier>-sbi.go` file in it. Implement all the communication and initialization related logic of SBI in this file. This will include communication with the message queue and Redis cache from where it will obtain the necessary information.