Best practices for interacting with AngularJS and Web Service

Question

I have a small site that I implemented using AngularJS, C # and Entity Framework. The entire site is a one-page application and gets all its data from a single C # web service.

My question is about the interface that the C # web service should show. This time, the service can provide objects in a RESTful way, by providing them directly or as a DTO. Another approach would be for the web service to return an object for only one use case, so the AngularJS controller only needs to call the web service once and can work directly with the responding model.

To clarify, consider the following two snippets:

// The service returns DTOs, but has to be invoked multiple // times from the AngularJS controller public Order GetOrder(int orderId); public List<Ticket> GetTickets(int orderId); 

and

  // The service returns the model directly public OrderOverview GetOrderAndTickets(int orderId); 

While the first example provides a RESTful interface and works with a resource metaphor, it has a huge disadvantage of only returning pieces of data. The second example returns an object adapted to the needs of the MVC, but most likely it will be used in only one MVC. In addition, in the second scenario, you need to perform many mappings for common fields.

I found that from time to time I did both things in my web service and I want to get some feedback about this. I don’t really like work, although a few queries are, of course, problematic, and when they slow down the application too much, they need refactoring. What is the best way to develop a web service interface?

Answer 1

I would suggest using the REST approach, a general-purpose API design, rather than the only goal of a remote procedure call (RPC). While RPC will be very fast at the start of your project, the number of endpoints usually becomes a commitment when saving code. Now, if you only have less than 20 types of server calls, I would say that you can take this approach without biting badly. But if your project will live longer than a year, you will probably get many more endpoints than 20.

For leisure-based services, you can always add an optional parameter to describe the child records that this resource contains and return them for a specific call.

Answer 2

There is nothing wrong with the RESTful service returning child entities or having an optional querystring parameter to switch this behavior.

public OrderOverview GetOrder(int orderId, bool? includeTickets);

When you return a ticket in an order, each ticket contains a property related to the URL endpoint of that particular ticket (/ api / tickets / {id} or something else), so the client can work with the ticket regardless of order

Answer 3

In this particular case, I would say that it depends on how many tickets you have. Let's say you need to add a pagination for tickets, do you want to receive an order every time you receive the next set of tickets?

You can always execute several requests and resolve all promises at once through $ q.all ().

Answer 4

Best practice is to end HTTP calls in an Angular service, which can be referenced by several Angular controllers.

With this, I do not think that 2 calls to the server will be a huge damage to you. And you don’t have to change the web service or add new Angular services if you want to add new views to your site.

Generally, an API should be written no matter what it consumes. If you pressed the time, and you are sure that you will never have to consume it from any other part of the client, you can write it specifically for your web application. But in general, how this happens.