My understanding of web services is that they are used to provide distributable functionality. However, as RESTful web services can return HTML and show this HTML as a regular web page in the browser, we then have a view rather than business logic. Is this ever useful or is it a violation of the separation of concern principle?
You are confusing something here.
REST is a web api design model and thus focuses on the integration of different applications rather than the internal structure of those.
That being said, REST is a very relaxed model. However the corner stones of a rest system are:
Its state less
You do not have some kind of a session like with soap, where you first authenticate and then get a session id and can perform actions. In rest every call is independent and has all the data/information needed to be processed and does not rely upon any preceeding or sucessing calls
every service is uniquely adressable by a uri
there are oprations that must meet certain criteria
for example a simple web server usually servers GET requests, those must be safe, meaning they will not modify anything, they are read only
here is a good article...
http://www.codeproject.com/Articles/253944/Representational-State-Transfer-A-Short-Walkthroug
Related
I am trying to integrate our third party application with NetSuite. I want to be able to import sales invoice details generated from our third party system (which uses REST API) into the NetSuite invoice form.
The frequency of import is not too crucial- an immediate import will be ideal, but sending data once a day is fine as well.
I want to know what I have to use to do this API integration - SuiteTalk, RESTlet or Suitelet.
I am completely new to this topic and after a few days of research, I learned that there are 3 options for an API integration with netsuite (Suitelets, restlets and suitetalk which comprises REST and SOAP based web services). I also learned that there are scheduled scripts and user events, but I'm not too clear on the idea.
I need some help identifying which integration option I should choose.
Any and all information about netsuite API integration is appreciated!
I would avoid REST/SOAP. SOAP is outdated, and REST is incomplete and difficult to use.
Suitelet's are for when you want to present your own custom UI to frontend users, like a special new kind of custom form not relevant to any particular record. Probably not what you want.
What you probably want is to design a restlet. A restlet is a way for you to setup your own custom url inside NetSuite that your program can talk to from outside NetSuite. Like a webpage. You can pass in data to the restlet either inside the URL, or inside the body of an HTTP request (e.g. like a JSON object), and you can get data back out from the body of the HTTP response.
A restlet is a part of SuiteTalk. The method of authenticating a restlet is the same for the method of authenticating a request to the REST API. So, learning about SuiteTalk is helpful. The code you use to write the restlet, SuiteScript, is the same kind of code used to write suitelets and other kinds of scripts.
So you will want to learn about SuiteTalk, and then, in particular, SuiteTalk restlets.
this is a really subjective issue.
It used to be that SOAP/SuiteTalk was a little easier in terms of infrastructure and since Netsuite's offerings are ever changing the REST/SuiteTalk might fill this space in the future.
Since Netsuite deprecated the Full Access role setting up integrations almost always involves the integrator having to provide a permissions spec. The easiest way to do that is via a Bundle. For token based authentication (TBA) there also needs to be an integration record from which you need Consumer Id and Secret Tokens.
So as of this writing the set up for SOAP/SuiteTalk and RESTLets is roughly the same. The easiest way to communicate these is with a bundle so if you are a Netsuite dev with a dev account you can set these up in a bundle and have your customer import them.
So equal so far but differences:
SOAP/Suitetalk is slow. IMO not suiteable for an interactive interface
SOAP/Suitetalk the code is all in your external app so changes to the code don't require any changes in the target account.
RESTlets can be pretty speedy. I've used these for client interactions.
Updates require re-loading your bundle or overwriting your bundle files in the target account (with the resulting havoc if an admin refreshes the bundle)
RESTlets give you access to the features of the account on which you are running so that code can run appropriate chunks For instance features such as matrix items, multi-location inventory, one-world, pick/pack/ship, volume pricing, multi-currency will all change the data model of the account your code is running against. RESTlets can detect which features are enabled; SOAP/SuiteTalk cannot.
So really the only advantage at this point that I see for SOAP/Suitetalk is that code updates don't require access to the target account.
Who is making the changes? If it is your NetSuite developers, then your options are SUITELET or RESTLET.
If its your third-party application team, they own the code and the process and do all their work sitting outside of NetSuite - your option is SUITETALK/SOAP. Of course, they need to know something about NetSuite, but your business analyst would be sufficient to support them. As of 2020.1+, there is also support for native REST APIs in addition to SOAP in case you still want to use REST, but not write your own RESTLETS.
As the above comments mention, Suitetalk does perform a little slower than calling RESTLETS. So that maybe one of the deciding factors.
You may consider SUITELETs for integration only if you want to bypass all authentication schemes, by setting the suitelet as public. Highly inadvisable though.
If the third-party application supports REST APIs, you could call them directly from within NetSuite - either from user events or from scheduled scripts.
You can also consider iPAAS platforms like Dell Boomi, Celigo, Jitterbit, etc. These are general-purpose integration platforms, and make connecting one platform to another easy, with minimal coding. If your Company is already invested in these iPAAS platforms for other enterprise applications, then the choice is that much simpler.
In my company we develop internal products and usually this products must be integrated (typical scenario). Our solution is always use SOA web services for this kind of task.
This is a solution that forces different products to develop same UI interfaces, and the responsibility of this interfaces or process is sometimes not clear between our teams.
I want to propose an alternative solution, I think that sometimes each product publish SOA web services but in addition publish web-pages, that other products can call to reuse.
for propose it in the work, I want document my-self because I suppose that this kind of integration is already invented, and have a name, examples, tools, best-practices...
any orientation?
To me it looks like a mistake to share entire UIs across applications. This will violate the separation of concerns principle, and will couple applications to each other. Also, you will end up losing autonomy because an external application will control how your UI looks. You will have all kinds of issues, related to the inter-dependencies between applications. These are the first that come to mind:
I assume the information is not public. If so, you'll need single sign-on between applications. In order to implement some level of security (at the very least authentication) you'll need to integrate all your applications within a single sign on-solution or invent some kind of convention for passing tokens between applications.
It will be very hard to implement even primitive authorization if needed, because naturally roles in different systems vary, especially across business domains.
If you have to filter any data by some property, it will have to be transferred in the request to the central application that holds the GUI prior to displaying. The whole processing of data and preparation for visualization will then be responsibility of this central UI system. This will lead to insane amount of caller-specific rules for each caller that uses the central UI.
Any complex UI required by applications will still have to be implemented locally, so you only solve the issue partially.
Here is what I would do in your case if I really must implement central UI, although I advice strongly against it and would prefer sticking to SOA with some kind of middle ware (ESB or even more primitive EAI software that limits point-to-point integration). You can decide for yourself if it is worth the time and effort:
I would only offer a very limited version of UI that is 100% based on the service layer that already exists and is generated automatically. This means - if you change the service the UI accommodates the new data and displays it automatically. If an application needs complex visualization it must still use the Service layer to retrieve data and implement custom UI locally. In genera, it will be better if UI and visualization are controlled by each application separately. This is much more agile and future-proof.
Hope this helps!
At my company we are redesiging our e-commerce website. HTML and CSS is re-written from the ground up to make the website responsive / mobile friendly.
Since it concerns one of our biggest websites which is responsible for generating of over 80% of our revenue it is very important that nothing goes "wrong".
Our application is running on a LAMP stack.
What are the best practices for testing a major redesign?
Some issues i am thinking of:
When a/b testing a whole design (if possible) i guess you definitaly
dont want Google to come by and index youre new design (since its
still in test phase). How to handle this?
Should you redirect a percentage of the users to a new url (or
perhaps subdomain)? Or is it better to serve the new content from the
existing indexed urls based on session?
How to compare statistics from a Google Analytics point of view?
How to hint Google about a new design? Should i e.g.
create a new UA code?
Solution might be to set a cookie only for customers who enter the website via the homepage. Doing so, you're excluding adwords traffic and returning visitors, who might be expecting an other webdesign, serve them the original website and leave their experience untouched.
Start the test with home traffic only, set cookie and redirect a percentage to a subdomain. Measure conversion rate by a dimension in Google analytics, within same analytics account. Set a 'disallow subdomain' in your robots.txt to exclude the subdomain from crawling by SE's.
Marc, You’re mixing a few different concerns here:
Instrumentation. If you changes can be expressed via HTML/CSS/JavaScript only, i.e. optimizational in nature, you may be able to instrument using tols like VWO or Optimizely. If there are server side changes too, then a tool like Sitespect (any server stack) or Variant (Java only) might be in order. The advantange of using a commecial product is that they provide a number of important features out of the box, e.g. collecting experiment data, experience stability (returning user sees the same experience), etc. You may be able to instrument on your own, but unless you’re looking at a handful of pages, that typically is hard, particularly if you want to do it outside of the app, via the DevOps mechanisms.
SEO. If you get your instrumentation right, this shouldn’t be an issue. Public URIs should not differ for the control and variant of the same resource.
Traffic routing. Another reason to consider a commercial tool. They factor that out of your app and let you set percentages. Some tools, like Variant, will allow you to write custom targeters, e.g. “value” users always see control.
I'm designing the architecture for a new web application.
I think that communications between the backend (server) and the frontend should be JSON only.
Here are my arguments:
Its the client responsibility to manipulate and present data in its own way. The server should just send to the client the raw information needed.
JSON is lightweight and my application might be used by remote clients over poor mobile connections
It allows multiple front-end developments (Desktop devices, mobile
devices) and has the potential to create an API for other developers
I can't see any counter-argument to this approach, considering that we have internally the frontend skills to do almost everything we need from raw JSON information.
Could you provide counter-arguments to this JSON-only choice so that I can make a more informed choice?
There must be some as a lot of backend frameworks (think about the php ones) still advertise HTML templating to send HTML formatted responses to the clients.
Thanks
UPDATE: Even though I researched the topic before, I found a similar and very interesting post: Separate REST JSON API server and client?
There are many front end based framework already in market which support a Json very efficiently,some of them are backbone,underscore,angular etc.Now if we talk about backend,we generally use REST based communication for such type of application.So i think this type of architecture already exits in market and working very well,specially if i talked about mobile based application.
Although this question is dead, I think I should try to weigh in.
For all the reasons you stated and more, communication between the back-end and front-end via only JSON files is maybe the best way available, as it provides a more compartmentalized structure for your web application, and at the same time drastically reduces the data sent over your users' connection.
However, some drawbacks that are a direct consequence of this are:
Need for a lot more JavaScript front-end development (as the HTML structure is not being sent by the server and needs to be created in the client)
It shifts the pressure from the server to the client, thus there is more JavaScript for the client to run (this can sometimes be a problem especially for mobile users)
I'm not a Web Developer, and I don't know a lot about the web application frameworks out there.
Recently, however, I got into Wt. It's a web framework written in C++ (that's why I got into it), but what impressed me the most is the idea it's based on.
Its API is different from any web framework I ever heard of (CppCMS, Yii, Django, Pylons, Zope, Drupals, Java Servlets, Struts ...): a new Application object gets created for any user session, and it stays alive until the session expires (only at this point the Application object gets destroied). This Application object works like a desktop window: you put Widgets in it (widgets like forms, links, labels ...); when the user clicks on a link (when the HTTP server receives a new GET/POST request) a function gets called on the object tight to the user session (in a nice Signal/Slot way), which can remove/add/change the widgets, thus changing the page the user will see.
As I said, I'm not very skilled with web frameworks, I develop almost only desktop applications; maybe for this reason I think this paradigm behind Wt is great.
I'd like to know what are the pros and cons of this framework API in respect to the other ones, and if there are other frameworks (also in other languages) based on the same concepts.
Wt is a great framework for its intended range of applications.
Wt is great for :
web apps tightly coupled to a session, i.e.
made to be accessed only by users that are logged in (except the landing page)
display a lot of user-dependent content (so not for a wiki)
relying heavily on state
web apps that need to have a lot of controls/buttons and user input.
For exemple, I plan to write a browser MMORPG. Pages will all be having a state tied to a user, and there will be a lot of buttons. Wt is perfect for that. I used to be a Ruby on Rails developper, and switching to Wt for this kind of app was a great moment. It's increadibly cumbersome to design forms with traditional frameworks that try to enforce pure REST.
Wt would also be perfect for a control interface on some process. For example, an interface allowing your customers to configure their adword campain, etc.
Of course, using Wt is not perfect regarding control and separation, but it allows extremely fast development when you need only the "classic" features (buttons, editors, etc.)
So as a rule of thumb, if you are trying to put a desktop application on the web (which is a great idea, removing the need to deploy and update on your customers' machines), Wt is a good candidate.
Also, if you are interfacing with an existing C++ codebase, Wt has an advantage.
I think this is generally bad idea.
Web application is very different from GUI one and there are many reasons:
99% of the web is about the content rather then about iteration.
You go to web to get or share content rather then to do some real time interaction
like drawing a picture, working with spreadsheet or anything else.
Web is content driven rather then "event driven" interactive application.
This has strong impact on how do you create most of web - you bring information
to user rather then interact with him.
The server and client programming is very different
There are some web GUI applications like e-Mail, Chats clients but to perform well
they require very good separation between the client side written
in high quality Java Script and the high quality server side backend that is used
over AJAX for content retrieval.
Hiding this separation like Wt does or (other known frameworks) lead to crappy
software and generally brings more problems then solutions in long run.
Because it should be very clear separation between server side and client side jobs
as some require real time response and some don't.
When you try to solve all this in one wait for problems. Note, there are client-server
solutions for GUI (see X-Server as example) but unlike web they designed for this
and rather work more like IPC rather then client-server solitions.
The web is stateless most of the time.
Or to be more correct the state usually keeps quite small amount of data.
Creation of instant session object is nice idea until you need to...
Scale up save state in long terms then this model becomes not so good, of course
this not "forced" model by Wt but it is general concept that fits certain concept
and some does not.
Bottom Line
If you want to design good GUI like web application. Start learning JavaScript and use good GUI JavaScript frameworks that fit well to GUI even driven design. Then combine them with some server side API using some interaction RPC model like Json-RPC, XML-RPC and other
AJAX tools.
This is the way to do things right for highly interactive applications.
If your application is more content oriented then most of server side web
frameworks do great job - concentrate on server side with its great tools suitable
for the job.
All in one solution? It just does not work...
Disclosure: I'm developer of CppCMS and I think Wt just goes in wrong way.
ASP.NET is similar; it has the same goal to make web development look like desktop application development.