Tag Info

New answers tagged

1

Yes, Rest API is very powerful for your scenario Expose all of your services through API endpoints. Always consider doing following when building Apis Authentication - have an strong authentication system in your API, like token based authentication ( Json web token) Authorization - every single API need to be access controlled, have the user ...


-1

It is now 2015. I would have hoped that SOAP has died by now, but it still lingers like a bad smell. For anything but the most basic of "example" applications, integrating with a SOAP service is frought with challenges. It is a complex architecture, with many options at multiple levels, combined with the quirks of multiple implementations and subtle (and not ...


0

You'll have to authenticate to a single system that, in turn handles the connections to the other services. Then the user should see a single 'logon' user and a single website. The back-end then has to deal with retrieving data and aggregating it for display. The service will have to have knowledge of all the other service's authentication mechanisms, ...


0

I don't think the separation of projects or repositories is really the important decision - the crucial thing is that the layers of the application are separated with clear interfaces between them. So you can choose to go with a single project early on but split out into multiple projects or repositories as the application grows. If you have tangled your ...


2

In layman's words Since one back-end can have more than one front-end, it doesn't make sense to put the back-end codebase together with any particular front-end codebase in the same versioning system project/branch.


1

On the conventional wisdom that states that you should only throw an exception when a condition occurs that you can't handle in your code we tend to focus on the definition of an exceptional condition but ignore the definition of what it means to handle the exception. A process may encounter a exception communicating with a particular node and may handle the ...


3

You seem to have some misunderstandings about exceptions, so let's try and clear those up first. Throw an exception when some condition occurs that you can't handle in your code. For example, if your code is supposed to open a file and do something with that file, but the user supplies a path to a file that does not exist, then you should throw an ...


2

When it comes to API authentication, those are the three most used models (in random order): Credentials are sent with every response. Credentials are sent once to generate an access key. The access key is then sent with every request. Credentials are sent once, and then a session (relying on cookies) is used to avoid repetitive authentication. Since one ...


1

You should design your backend around the resources you are exposing from the backend. These do not have to match up exactly to your model (the exposed resources and the internal model are two separate things), but often you will have a lot of overlap. For example you might have a "user" model object and a "user" resource exposed by the server. A ...


1

If this process really does take a long time, you could also consider moving the long-running work out of process. For example, when the request is handled by your Web API, you could write a message into something like a Message Queue and have MSMQ on the server activate a separate process to perform whatever work is indicated by that message. How that ...


1

Your three steps belong in the Model, not the Controller. If it's a long-running operation, make it an asynchronous one. See Using Asynchronous Methods in ASP.NET MVC 4 and C#5, ASP.NET MVC 4, and asynchronous Web applications for more information.



Top 50 recent answers are included