We are in the process of designing/creating restful web services that will be consumed client side using XHR calls from various web pages. These web pages will contain components that will be populated by the data retrieved from the web services.
My question is, is it best to design the return data of the web services to match specifically what the client side components will require for each page? Therefore, only one XHR call will be required to retrieve all the data necessary to populate a specific AJAX component or to update a specific page. Or is it more advisable to develop generic web services, that match for instance a database schema, and will require multiple XHR calls client side to retrieve all the data to populate an AJAX component? The second approach seems to lead to some messy coding to chain calls together to retrieved all the data required before updating an AJAX component.
Hopefully this makes sense.
You should always design services based on what they are to provide. Unless you need a service that retrieves rows from the database, don't create one. You may find you need a service that returns complete business entities - they may be in multiple tables.
Or, you may just need a service to provide data for UI controls. In that case, that's what you should do. You may later find that two operations are returning almost the same data, so you may refactor that into one operation that returns the data for both.
My general rule of thumb is to do what ever is the smallest to transmit over the ajax call. In theory, the more data that is sent to the client the slower the update process. This, of course, would necessarily mean specific services for specific pages.
Related
I have a Typical SOA web application which has the following components as expected.
The Web Client - Sprinv MVC
SOAP Services - Spring
The Reference Data is centralized which is exposed thru its own SOAP Services.
The SOAP webservice responses have codes for elements(like CountryCode, CityCode etc).
I need the suggestions as to what should be the best approach to for ex display the Country Description instead of the country code (which needs another SOAP call to reference data and same with other codes) on the web page ?
Few options are like:
Write a custom tag library which would do the necessary calls and get the data.
Fetch all the ReferenceData descriptions and put it into some kind of HashMap, add it to the model to be consumed by the web page.
Any other better ways please advice.
Since it's reference data, no one expect it to change very often, right? Retrieve them once and serve them up using #ModelAttribute. See here.
Spring MVC is still server side, so it can handle very large data e.g. all the street addresses in US. You simply need to make sure you add some sort of filter if you don't want to serve the entire collection. And simply partial update these reference data with the latest on regular basis.
I'm working on a web application that need to expose Json API for external apps and I'm planning to do an API centric architecture.
So basicly, the app will juste contains view/controllers for the web interface. the controllers will use Route::dispatch to create a request to the api part of the site (another controller in a package, but in the same laravel installation), then parse the result, and create view accordingly.
So I'm wondering what are the drawbacks, performance wise, of using this sort of architecture?
If each controller is writing the logic to internally dispatch another request then I'd consider abstracting that away from the controller and in to your own dispatcher. I doubt there would be a huge performance overhead. The application (as far as I know) doesn't get booted twice so you don't have to worry about that.
The only thing you need to be aware of is the input for the main request being used. Something you should take into account inside your dispatcher. Refer to this answer for more information.
You can also read more on consuming your own API.
Do I need to send individual entity updates to WebAPI, or can I POST an array of them and send them all at once? It seems like a dumb question, but I can't find anything that says one way or another.
Brad has a blog post that talks about implementing batching support in Web API.
Also, Web API samples project on codeplex has a sample for doing batching in web API hosted on asp.net.
It seems like WEB API 2 has support for this
From the site (Web API Request Batching):
Request batching is a useful way of minimizing the number of messages
that are passed between the client and the server. This reduces
network traffic and provides a smoother, less chatty user interface.
This feature will enable Web API users to batch multiple HTTP requests
and send them as a single HTTP request.
There are a number of samples for different scenarios on this page.
https://aspnetwebstack.codeplex.com/wikipage?title=Web+API+Request+Batching
You will have to create an action that accepts a collection of items.
If all you have is an action that accepts a single item than you need to send separate requests.
With batching always think about how you would report the failures and whether a failing of a single item should invalidate the whole batch.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js
I am using Controllers as services to return HTML/JSON. Is there a proper technical name for what I am doing here?
A user triggers an event
Perform AJAX GET
Request handled by Controller
Return HTML/JSON
Populate front end HTML object(s) with result
This strikes me as a service oriented design. It has the benefit of behaving like a RIA app. I have heard of "RESTFUL" services, but I don't know if this fits the bill.
I use the exact same schema in our main app. It's a subset of Service Oriented Design/Architecture. You actually use "services", such as: Login, CreateBlogPost, DeletePicture, Register, Connect and so on. But I believe that services serve broader goals. For example, exposing an API, which could be essentially accessed in the same manner you describe but respond to more HTTP verbs other than GET: POST, HEAD, PUT, DELETE. This is a RESTful service, as you mentioned.
So, to answer your question, the schema you describe plays a role in a good architected RIA. I don't believe it has a unique name of its own (besides being part of SOA).