ASP.NET 和 C#：你在哪里存储 rest 客户端 Z572D4E421E5E6B20BC11D815EEA

Question

I have my rest client url hard-coded in my code-behind, but upon peer-reviewing my code, I was asked to move that url to the config file so that it can be changed for each environment.

Visual Studio 2019 now complains because my rest client url has an invalid = sign as token in the url itself, and it expects ; as token instead.

Has anyone ever come across this, and is it correct to move the rest client to the config file? In theory that should not change.

Can't share the full url, but the part that is highlighted as error is this: version=2.0&details=true .

Answer 1

I found the answer. The problem is in the & symbol itself. Once converted to & , the errors Visual Studio was highlighting were gone and my solution worked again.

Answer 2

If i will do that i will save in config file only base url like this

  "WebConfig": {
    "SmsCenterApi": "https://some_site.com/SendService"
  }

and in code I can complete the link

string url = WebConficData.SmsCenterApi+"version=2.0&details=true";

andafter that I can use url to make some request. For multi-environments web.config and appsettings is avesome. You just change base url for each env and that's it.

Answer 3

I think the answer to your questions

where do you store the rest client url?

is it correct to move the rest url to the config file?

is dependent on how you implement the rest request to that url. As you do not show any information on how you implement the rest call, I would like to show you one possible way and hopefully give you an impression about which things you should consider when implementing a solution.

So we can basically (for the sake of completeness) split an rest-endpoint url into two parts which might affect our implementation.

The base url:

"https://www.some-nice-name.com/SomeEndPoint"

and the parameters

?key1=value1&key2=value2

having this in mind, you could go the way and split them up, storing the base url and the parameters in two different nodes/attributes in a config file:

{
    "BaseUrl" : "https://www.some-nice-name.com/SomeEndPoint",
    "UrlParams" : "?key1=value1&key2=value2"
}

Or in one node/attribute, or even split each single parameter pair ("key1=value1") into own fields. And so on, and so on......

Anyway, if we now jump into our C# code and implement the Rest call, we have a wide range of different possible solution. For this example I will show you how to use the RestSharp NuGet package and why it might influences our decision on the above question.

So one basic example:

// I will not show the implementation of ReadYourConfigStuff() because its fairly clear what should happen here
var config = ReadYourConfigStuff(); 

// Give the BaseUrl to our REST client
var restClient = new RestClient(config.BaseUrl);

// Just taking GET as we have some GET Parameters
var restRequest = new RestRequest(Method.GET); 

so far so good. But we still miss our parameters right? Let's go ahead:

// RestSharp gives us a very nice tool to add GET parameters to our request
restRequest.AddParameter("key1", "value1");
restRequest.AddParameter("key2", "value2");

That looks quite different to what we added to our config file, does it? Yes it does. As RestSharp gives us a tool at hand which allows to add parameters one by one, we are free to choose how to store and maintain those in our code. And if we have a look on the AddParameter defintion

public IRestRequest AddParameter(string name, object value);

we see that the second parameter can be any object. Amazing!

So my answer to your question is: Yes you can store it in the config file, but does it fit to your implementation? Are the parameters fix or do they change? How does your favorite tooling would like you to implement the rest request?

Based on the answers to these questions, I would take a decision rather to use a config file or not.