I have 2 question :
1.what is best practice for REST API method GET if there are many condition with the parameters.
example :
i have customers API and the user wants the api with request parameter like these :
idnumber and mobilephone
name (can use contains if user input %) or mobilephone
idnumber and idtype or date of birth
should i make 3 custom api with the same route for each commbination of parameters?
i ve searched everywhere but i cant find the answer, most article only share common best practice like these :
api/customer -- get all customer
api/customer/{id} -- get customer by id
2.Regarding the response api
example :
I have customers API and the response is like this :
- CustomerID
- CustomerName
- IDNumber
- MobilePhone
- Address
lets say i have 2 user that consume this API but i only want 1 user can see response with "mobilephone" and "address" but another user only customrid,customername and idnumber , the question is how can i make the api?should i create 2 api?
sorry for my bad english
i googled everywhere but i cant find the right answwer please help
Let me attempt to answer these.
A typical way would be to still just create an api like api/customer. What you should expect from the user/application consuming the API is to pass in a Customer object(not in the literal OOP sense). Something like a json object
{
idnumber: "123",
mobilephone: "",
DOB: null
}
Something like this: https://weblog.west-wind.com/posts/2013/dec/13/accepting-raw-request-body-content-with-aspnet-web-api
When processing this object you can probably check the type of the user in the code. Is it a super-user or regular user(just an example). Based on this you can return an appropriate response.
I hope I understood your question correctly.
Regarding your first question, please try to make api calls distinct as possible.
1. For the above given example, you should ideally use three different methods as the validation logic will be different in each case.
2. Also, looking at scalability and maintainability, it will be real task to handle simple change without affecting the other two.
For your second query, you can integrate both the calls in a single method. Since the underlying model is same, generate a generic response and filter out the results accordingly. Or else, create a wrapper on model to generate customized response as per user.
But no need to expose two api calls for this.
always create different endpoint for each web api calls. if the parameters that sent are a different types for each scenario then you may be able to overload the conntroller method with the same name.
this is definitely requires two different endpoints, because the response model is different. this way you don't make alot of boxing and unboxing for the response datamodel.
[![class Program
{
static void Main(string\[\] args)
{
var customer = new Customer() { CustomerID = 666, CustomerName = "john", IDNumber = "john123", MobilePhone = "9834567899", Address = "Test address 1" };
//For user 1
var allewdProperties = new string\[\] { "CustomerName", "IDNumber", "CustomerID" };//For user 1
var json = JsonConvert.SerializeObject(customer
,
new JsonSerializerSettings() { ContractResolver = new CustomContractResolver(allewdProperties.ToList()) }
);
//Data for user1
Console.WriteLine("Data for user 1");
Console.WriteLine(json);
//for user 2
allewdProperties = new string\[\] { "MobilePhone", "Address" };//For user 2
json = JsonConvert.SerializeObject(customer,
new JsonSerializerSettings() { ContractResolver = new CustomContractResolver(allewdProperties.ToList()) }
);
Console.WriteLine("Data for user 2");
Console.WriteLine(json);
Console.ReadLine();
}
}
public class Customer
{
public int CustomerID { set; get; }
public string CustomerName { set; get; }
public string IDNumber { set; get; }
public string MobilePhone { set; get; }
public string Address { set; get; }
}
public class CustomContractResolver : Newtonsoft.Json.Serialization.DefaultContractResolver
{
IEnumerable<string> _allowedProps = null;
public CustomContractResolver(IEnumerable<string> allowedProps)
{
_allowedProps = allowedProps;
}
protected override IList<JsonProperty> CreateProperties(Type type, MemberSerialization memberSerialization)
{
return _allowedProps.Select(p => new JsonProperty()
{
PropertyName = p,
PropertyType = type.GetProperty(p).PropertyType,
Readable = true,
Writable = true,
ValueProvider = base.CreateMemberValueProvider(type.GetMember(p).First())
}).ToList();
}
}][1]][1]
Related
I am stumped on how to save/pass MongoDB UpdateDefinition for logging and later use
I have created general functions for MongoDB in Azure use on a collection for get, insert, delete, update that work well.
The purpose is to be able to have a standard, pre-configured way to interact with the collection. For update especially, the goal is to be able to flexibly pass in an appropriate UpdateDefinition where that business logic is done elsewhere and passed in.
I can create/update/set/combine the UpdateDefinition itself, but when i try to log it by serializing it, it shows null:
JsonConvert.SerializeObject(updateDef)
When I try to log it, save it to another a class or pass it to another function it displays null:
public class Account
{
[BsonElement("AccountId")]
public int AccountId { get; set; }
[BsonElement("Email")]
public string Email { get; set; }
}
var updateBuilder = Builders<Account>.Update;
var updates = new List<UpdateDefinition<Account>>();
//just using one update here for brevity - purpose is there could be 1:many depending on fields updated
updates.Add(updateBuilder.Set(a => a.Email, email));
//Once all the logic and field update determinations are made
var updateDef = updateBuilder.Combine(updates);
//The updateDef does not serialize to string, it displays null when logging.
_logger.LogInformation("{0} - Update Definition: {1}", actionName, JsonConvert.SerializeObject(updateDef));
//Class Created for passing the Account Update Information for Use by update function
public class AccountUpdateInfo
{
[BsonElement("AccountId")]
public int AccountId { get; set; }
[BsonElement("Update")]
public UpdateDefinition<Account> UpdateDef { get; set; }
}
var acct = new AccountUpdateInfo();
acctInfo.UpdateDef = updateDef
//This also logs a null value for the Update Definition field when the class is serialized.
_logger.LogInformation("{0} - AccountUpdateInfo: {1}", actionName, JsonConvert.SerializeObject(acct));
Any thoughts or ideas on what is happening? I am stumped on why I cannot serialize for logging or pass the value in a class around like I would expect
give this a try:
var json = updateDef.Render(
BsonSerializer.SerializerRegistry.GetSerializer<Account>(),
BsonSerializer.SerializerRegistry)
.AsBsonDocument
.ToString();
and to turn a json string back to an update definition (using implicit operator), you can do:
UpdateDefinition<Account> updateDef = json;
this is off the top of my head and untested. the only thing i'm unsure of (without an IDE) is the .Document.ToString() part above.
I'm working on a self hosting rest api used to monitor de status of several servers.
I was tasked that, when everything is working correctly, I should only return
{"response":"ok"}
But, when there's an error on queried server, or servers, I must return
{ "response" : [ {"agent":"<server>:<port>","port":"<port>" ,"Error":"<Description of the error>"} ] }
I was thinking on building a helper class to build object on this schema and returning them over the rest api
public class HelperErrorResponseClass
{
public string agent { get; set; }
public string port { get; set; }
public string Error { get; set; }
}
This is no problem, the issue is, how to deal when everything it ok. I have this Api response helper class
public class Response
{
public string response { get; set; }
}
But I'm seeing that I'll need to change the response property to List<HelperErrorResponseClass> in order to send the error response. Do you think that, if I stringify the List<HelperErrorResponseClass> object with Json.Net it will be returned in the desired format?
Edit: Forgot to add that, I-m using Web Api to build the rest service.
UDPATE:
After further research, I found a way to work this out.
Following this post, I was able to rewrite the helper classes like this
[DataContract]
[KnownType(typeof(List<HelperErrorResponseClass>))]
public class Response
{
[DataMember]
public object response { get; set; }
}
[DataContract]
public class HelperErrorResponseClass
{
[DataMember(EmitDefaultValue = false)]
public string agent { get; set; }
[DataMember(EmitDefaultValue = false)]
public string port { get; set; }
[DataMember(EmitDefaultValue = false)]
public string error { get; set; }
}
This work to fulfill my and my client needs... except for one little thing. When I get the result from a List, and given that I added the KnownTypes directive, my response is now this
{"response":[{"__type":"HelperErrorResponseClass:#AppCommonLib","Error":"ERROR","InstanceId":"<InstanceId> : <Port>","PortType":"<PortType>"},{"__type":"HelperErrorResponseClass:#AppCommonLib","Error":"ERROR","InstanceId":"<InstanceId> : <Port>","PortType":"<PortType>"}]}
Any idea how to get rid of that __type property of the response? make that it must be explicit to only return the declared properties of the helper class?
Simplest way to deal with this is to set the return type on the handling function to string, then you can check for errors and do something like;
//pseudo code to give an idea
if (errorsList.Count() > 0)
{
return JsonConvert.SerializeObject(errorsList);
}
else
{
return JsonConvert.SerializeObject(new Response("ok"));
}
Now this being said... Unless the people providing requirements aren't at all flexible you should just redo the design. How about just returning the errors array and the person calling the API can infer that if it's length is 0 then everything is working OK. Seems pretty straight forward, right? You could also just put all the properties on one object and those fields would just come back as null or empty strings. Or you could change you serializer settings to exclude them if they don't have a value.
Keep things simple and use an anonymous type.
if (condition)
{
return JsonConvert.SerializeObject(new { response = new { agent = "x", port = "y", error = "z" }});
}
else
{
return JsonConvert.SerializeObject(new { response = "ok"});
}
More info:
https://msdn.microsoft.com/en-us/library/bb397696.aspx
I personally don't think you need a Response class, especially that it is of object type. IMHO, you've overcomplicated the very simple issue that you have. It is not only the __type, but also other info like HelperErrorResponseClass:#AppCommonLib that isn't supposed to be there.
Another Issue you have is the incorrect name of the HelperErrorResponseClass class. This is not a helper class. It is a standard data-object class.
A helper class is a class filled with static methods. It is usually used to isolate a "useful" algorithm.
This is how I would do it:
I'd get rid of the Response class.
I'd use your original simple HelperErrorResponseClass class, but rename it to something more meaningful like ErrorDetails.
I'd return the response like this:
.
if (errorsList.Count() > 0) {
return JsonConvert.SerializeObject(new { response = errorsList});
}
else {
return JsonConvert.SerializeObject(new { response = "ok"});
}
However, if you really want to stick to your updated solution, an easy way to get rid of the __type is simply removing it from the final serialized string:
if (errorsList.Count() > 0) {
string r = JsonConvert.SerializeObject(new { response = errorsList});
return r.Replace("__type", "");
}
else {
return JsonConvert.SerializeObject(new { response = "ok"});
}
I'm currently developing a SPA in Angular, and so I've created a REST service using ServiceStack. I am also using ServiceStack's default authentication and authorization solution, which allows me to decorate services with the Authenticate attribute, and also allows me to authorize roles.
However, since my application has users, and users own resources, I need a way to restrict non-authorized users from performing certain actions. Furthermore, I would like to be able to create a single service for each discrete entity which can properly figure out what is safe to write to the database and what is safe to return to the user depending on their level of authorization.
So as an example, let's say I've created a service to handle operations on a Group entity. One of the actions I allow on a Group is to get the details for it:
Route: api/groups/{Id}
Response: Name, Description, CoverImageUrl, Members
However, depending on who the user is, I wish to restrict what data is returned:
Not authenticated: Name, CoverImageUrl
Authenticated: Name, CoverImageUrl, Decription
Member of requested group: Full access
Admin of website: Full access
So one simple approach to doing this is to create 3 different response DTOs, one for each type of response. Then in the service itself I can check who the user is, check on their relation to the resource, and return the appropriate response. The problem with this approach is that I would be repeating myself a lot, and would be creating DTOs that are simply subsets of the "master" DTO.
For me, the ideal solution would be some way to decorate each property on the DTO with attributes like:
[CanRead("Admin", "Owner", "Member")]
[CanWrite("Admin", "Owner")]
Then somewhere during the request, it would limit what is written to the database based on who the user is and would only serialize the subset of the "master" DTO that the user is permitted to read.
Does anyone know how I can attain my ideal solution within ServiceStack, or perhaps something even better?
The direct approach is the easiest, but you could also take advantage of custom filters attributes.
[Route("/groups/{Id}"]
public class UpdateGroup
{
public int Id { get; set; }
public string Name { get; set; }
public string CoverImageUrl { get; set; }
public string Description { get; set; }
}
[RequiresAnyRole("Admin", "FullAccess")]
[Route("/admin/groups/{Id}"]
public class AdminUpdateGroup
{
public int Id { get; set; }
public string Name { get; set; }
public string CoverImageUrl { get; set; }
public string Description { get; set; }
//... other admin properties
}
Service implementation:
public object Any(UpdateGroup request)
{
var session = base.SessionAs<AuthUserSession>();
if (session.IsAuthenticated) {
//.. update Name, CoverImageUrl, Description
}
else {
//.. only update Name, CoverImageUrl
}
}
public object Any(AdminUpdateGroup request)
{
//... Full Access
}
What ended up being the most pragmatic solution for me was actually pretty simple. The basic idea is that whichever service requires row-level authorization should implement a GetUserRole method, which in my case returns the user's most permissive role.
protected string GetUserRole(Domain.Group entity)
{
var session = SessionAs<AuthUserSession>();
var username = session.UserName;
if (session.Roles.Contains("Admin"))
{
return "Admin";
}
if (entity.Id == default(int) || entity.Leader.Username.Equals(username))
{
return "Leader";
}
// More logic here...
return session.IsAuthenticated ? "User" : "Anonymous";
}
Then I can use the user's role to figure out what to let them write:
var entityToWriteTo = ... // code that gets your entity
var userRole = GetUserRole(entityToWriteTo);
if (new[] {"Admin"}.Contains(userRole))
{
// write to admin-only entity properties
}
if (new[] {"Admin", "Leader"}.Contains(userRole))
{
// write to admin or leader entity properties
}
// Etc.
And the same logic applies for reads: You populate a DTO with properties set conditionally based on their role. Later on when you return the DTO back to the client, any properties that you haven't set either won't be serialized or will be serialized with a null value.
Ultimately, this solution allows you to use a single service for a resource instead of creating multiple services each with their own request DTO. There are, of course, refactorings you can do that makes this solution more streamlined. For example, you can isolate all of your reads and writes to one part of your code which will keep the services themselves free of role checks and things like that.
So I have a Model Subscription which inherits from Azure's TableEntity class for use in a WebApi Get method as follows:
[HttpGet]
public IEnumerable<Subscription> Subscribers()
In this method, I do a Select query on my subscribers table to find all subscribers, but I only want to return a few of the columns (properties) as follows:
var query = new TableQuery<Subscription>().Select(new string[] {
"PartitionKey",
"RowKey",
"Description",
"Verified"
});
The definition for the model is below:
public class Subscription : TableEntity
{
[Required]
[RegularExpression(#"[\w]+",
ErrorMessage = #"Only alphanumeric characters and underscore (_) are allowed.")]
[Display(Name = "Application Name")]
public string ApplicationName
{
get
{
return this.PartitionKey;
}
set
{
this.PartitionKey = value;
}
}
[Required]
[RegularExpression(#"[\w]+",
ErrorMessage = #"Only alphanumeric characters and underscore (_) are allowed.")]
[Display(Name = "Log Name")]
public string LogName
{
get
{
return this.RowKey;
}
set
{
this.RowKey = value;
}
}
[Required]
[EmailAddressAttribute]
[Display(Name = "Email Address")]
public string EmailAddress { get; set; }
public string Description { get; set; }
public string SubscriberGUID { get; set; }
public bool? Verified { get; set; }
}
The following is the XML response of the API query:
<ArrayOfSubscription>
<Subscription>
<ETag>W/"datetime'2013-03-18T08%3A54%3A32.483Z'"</ETag>
<PartitionKey>AppName1</PartitionKey><RowKey>Log1</RowKey>
<Timestamp>
<d3p1:DateTime>2013-03-18T08:54:32.483Z</d3p1:DateTime>
<d3p1:OffsetMinutes>0</d3p1:OffsetMinutes>
</Timestamp>
<ApplicationName>AppName1</ApplicationName>
<Description>Desc</Description>
<EmailAddress i:nil="true"/>
<LogName>Log1</LogName>
<SubscriberGUID i:nil="true"/>
<Verified>false</Verified>
</Subscription>
</ArrayOfSubscription>
As you can see, the model not only has a few additional properties such as SubscriberGUID which I do not want to be serialized in the response (and since they are not in the select query, they are null anyway), but TableEntity itself has fields such as PartitionKey, RowKey, Etag, and Timestamp which are also being serialized.
How do I continue to use Azure tables but avoid serializing in the response these undesired fields I do not want the user to see.
Not disagreeing with the answer of using a specific DTO, but the Microsoft.WindowsAzure.Storage assembly now provides an attribute, the IgnorePropertyAttribute, that you can decorate your public property with to avoid serialization.
I haven't actually tried it yet but there is a method on TableEntity called ShouldSkipProperty() that checks a number of things before returning false (i.e. don't skip):
Is the Property Name one of "PartitionKey", "RowKey", "Timestamp" or "ETag" -> skip
Are EITHER of the getter and setter non-public -> skip
Is it static -> skip
Does the property have the attribute IgnorePropertyAttribute -> skip
Looks like it'll do the trick.
I would suggest using DTO (data transfer objects) to solve this type of issues. DTO's might mean more code (more classes) but would benefit you in the long term. You have much better control as to what would be put on the wire. They are better from a security standpoint too rather than using some serializer specific attributes to control what is being put on the wire.
Refer to this asp.net web API tutorial for more.
The use of the DTO is the way to go, IMHO, but to clarify, since it wasn't as obvious from the posts is where to implement to the DTO. I was hoping I could have just used it as part of the query, which I could not. Instead, I had to do this:
query.SelectColumns = new List<string> { "QuoteId", "RateId", "Date" };
var results = await MyCloudTable.ExecuteQuerySegmentedAsync(query, null);
return results.Select(d => new MyDto { QuoteId = d.QuoteId, RateId = d.RateId, Date = d.Date }).ToList();
You have to return your TableEntity derived object from your TableQuery, but since all the properties are null (from explicitly selecting the columns you want) there is no additional data on the wire. You then project into your DTO so you can return exactly the object you need.
You do not need to inherit from TableEntity class. You can use TableEntity.Flatten method to create a DynamicTableEntity from your Subscription class and write to table storage. And you can use TableEntity.ConvertBack method to recompose your subscription object when you read the DynamicTableEntity back from azure table storage. These static helper methods are available in Azure Table Storage SDK version >= 8.0.0
TableEntity.Flatten: https://msdn.microsoft.com/en-us/library/azure/mt775434.aspx
TableEntity.ConvertBack: https://msdn.microsoft.com/en-us/library/azure/mt775432.aspx
Eliminating the need for you to further write up converter classes between DTO s and Business Data Models
I need advice on how to return a limited set of data from an MVC controller.
Lets say I have a class that is constructed like so:
public interface ICustomerExpose
{
string Name {get; set;}
string State {get; set;}
}
public interface ICustomer: ICustomerExpose
{
int Id {get; set;}
string SSN {get; set;}
}
public class Customer: ICustomer
{
...
}
In my MVC project I have a controller action that returns customer data. The project is actually more like a web service as there is no View associated with the data... we use the XmlResult (provided by the MVCContrib project). The controller action looks like this:
// GET: /Customer/Show/5
public ActionResult Show(int id)
{
Customer customer = Customer.Load(id);
... // some validation work
return new XmlResult((ICustomerExpose)customer);
}
The above controller code does not work like I want it to. What I want to happen is that only the Name and State properties are serialized and returned in the XmlResult. In practice the whole customer object is serialized including the data I definitely don't want exposed.
I know the reason this doesn't work: you can't serialize an interface.
One idea floated around the office was to simply mark the properties Name and State as [XmlIgnore]. However, this doesn't seem like a good solution to me. There might be other instances where I want to serialize those properties and marking the properties on the class this way prohibits me.
What is the best way to achieve my goal of only serializing the properties in the ICustomerExpose interface?
Addendum:
For those interested in what XmlResult does here are the relevant parts of it:
public class XmlResult : ActionResult
{
private object _objectToSerialize;
public XmlResult(object objectToSerialize)
{
_objectToSerialize = objectToSerialize;
}
/// <summary>
/// Serialises the object that was passed into the constructor
/// to XML and writes the corresponding XML to the result stream.
/// </summary>
public override void ExecuteResult(ControllerContext context)
{
if (_objectToSerialize != null)
{
var xs = new XmlSerializer(_objectToSerialize.GetType());
context.HttpContext.Response.ContentType = "text/xml";
xs.Serialize(context.HttpContext.Response.Output, _objectToSerialize);
}
}
}
You can try this, however I am not sure if it works with xml serializers:
return new XmlResult(new { customer.Name, customer.State });
See this related question which recommends using an anonymous type.
// GET: /Customer/Show/5
public ActionResult Show(int id)
{
Customer customer = Customer.Load(id);
... // some validation work
var result = from c in cusomter
select new
{
Name = c.Name,
State = c.State,
};
// or just
var result = new
{
Name = customer.Name,
State = customer.State,
};
return new XmlResult(result);
}
Consider using, just for this one problem, XML literals in VB9 rather than serialization. Seriously. Just give it 20 minutes of your time. There's many options.
http://www.hanselman.com/blog/TheWeeklySourceCode30VBNETWithXMLLiteralsAsAViewEngineForASPNETMVC.aspx
http://www.hanselman.com/blog/XLINQToXMLSupportInVB9.aspx
http://blogs.msdn.com/dmitryr/archive/2008/12/29/asp-net-mvc-view-engine-using-vb-net-xml-literals.aspx
http://haacked.com/archive/2008/12/29/interesting-use-of-xml-literals-as-a-view-engine.aspx
http://www.infoq.com/news/2009/02/MVC-VB
For what you're doing, returning XML as a poor-man's Web Service, this is tailor-made.
I ended up just doing the XmlIgnore as co-workers suggested, even though this left me with some undesirable (or so I thought) behaviors.
To get around the fact that XmlIgnore would continue hiding properties that I might want serialized later I asked another question trying to find a way to around that issue. Cheeso came up with a great answer making the XmlIgnore the best route (in my opinion) to take.