Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
we're developing kind of a social network.
We first focused on mobile applications and thus we developed our own API (REST) using jboss as application server and everything is fine.
Now we are beginning the development of a website. We decided to build such website on top on the API we already have, so we won't have to worry about the database management.
My question is: what approach should I follow?
client-side calls (using ajax)
server-side calls (using e.g. php, python) to dynamically generate the html page
Do you have any suggestion?
Thanks,
Andrea
I like a mixed approach.
Direct client side calls into your REST layer will have issues with Authentication & Authorization.
So you need to have a server-side Facade that validates application session and then allows the calls to pass through to your backend.
This layer can employ pagination kind of logic if the REST APIs have them missing.
Sometimes an UI action would require you to manipulate the data structure or multiple REST calls to create the resulting view. Direct one-to-one mapping of UI action to backend REST calls may not be possible. There also this facade helps make the APIs more UI friendly.
Finally - for some static / cachable HTML fragments your server can generate the view from REST layer and cache it for faster serving.
So in summary
Use node.js or playframework kind of AJAX based UI to build the UI layer.
But to use a Facade that orchestrates, aggregates, transforms, authenticate, authorize the UI calls before hitting the REST layer - to keep the UI experience simpler.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am new in SAP.but i am confused b/w SAP UI5 and Webdynpro.I have some points of confusion.
(1) Is Webdynpro plays role like Servlets and JSP for middle ware programming.
(2) IS UI5 is replacement of Webdynpro.
(3) or UI5 is only a like front end programming like HTML,CSS,JAVASCRIPT etc.
Please find comments below for your questions:
(1) Is Webdynpro plays role like Servlets and JSP for middle ware programming?
Not Exactly, Web Dynpro ABAP is the SAP standard UI technology for developing Web applications in the ABAP environment. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench.It enables you to build business applications, which means that you can't change the look and feel with embedded HTML or Java Script.
(2) IS UI5 is replacement of Webdynpro.
No, UI5 is a JavaScript UI Library.
UI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice. It’s based on JavaScript, using JQuery as its foundation and follows web standards. It eases your development with a client-side HTML5 rendering library including a rich set of controls and supports data binding to different models (JSON, XML and OData)
With respect to END user you may quite true. But for a developer WebDynpro and UI5 are two different UI technologies.
(3) or UI5 is only a like front end programming like HTML,CSS,JAVASCRIPT etc.
Yes, Its a JavaScript UI framework/library along with that it supports data binding to your different data models as mentioned above.
Please find the comments below ( considering the differences between Web Dynpro and SAP UI5 ) :
Web Dynpro :ABAP framework to build web apps.
SAP UI5 : A Javascript application framework to build Web apps.
Web Dynpro does not play the role of a servlet/JSP as it is a complete UI technology for front-end development in ABAP. ( ABAP programming alongside plays a role of APIs ).
UI5 is a javascript framework makes efficient use of oData services(http rest API) to create template-based front-end applications as well.
Here, oData is mainly ABAP Gateway oData or HANA XS oData which serves as APIs residing only in the application layer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There has been a lot of hype over REST last few years, and I've tried to embrace the principle and understand it's benefits. Some things about REST still elude me, though. I'll try to be concise and to the point:
Can a web application be considered RESTful? What are the benefits of this? I can understand (to a point) advantages of RESTful service, which is to be used by many clients, but what is gained by using REST principles when developing application interface which is to be consumed by HTML/JS frontend?
REST mandates use of verbs which roughly map to CRUD operations and to which the server responds with representations which in turn put client in a new state. Does this imply that ALL actions on a resource must be done through modification/creation/deletion of that and possibly many other related resources? What about "atomicity" of such operations (i.e. transactions)?
REST compliant service is supposed to be self-descriptive (through HATEOAS principle), but the lack of metadata makes it impossible for a client to e.g. create a resource without knowing exactly what fields (and their types) are mandatory. This information must still be provided out-of-band. Is there something I'm missing here?
I could come up with more questions, but it will be enough for now if someone could clarify these points for me.
Some notes about your questions:
1) If your web application is a Single Page Application the simplest way to communicate with the server will be if it is a Rest service.
For a traditional web application I think is better that "controllers" communicate with a service layer using dependency injection.
3) Yes, of course the client needs to know the format of the data it is receiving. But AFAIK, Rest does not give any constrain about how this metadata has to be defined or transmitted.
The HATEOAS principle refers more to the discovering of related resources from a given one.
There exists different conventions to express that relations, see for example:
http://stateless.co/hal_specification.html
2) Every Rest action must be atomic. If you need a some kind of long operation, the usual is to create a resource that describes the operation. The state of the operation is retrieved from that resource, and you do whatever you want with the operation (i.e. Cancel it) interacting with that resource.
See an example of that here.
1.Usually REST architecture is designed when application is going to be used by different
by nature clients(external api consumers, mobile applications etc). In this case development costs will be paid back completely.
Developing truly REST application is not such a simple task to do. So,
if you know in advance that your application is to be used only by your client-side, probably,
you could consider 100% RESTfull approach as an overhead. But it does not mean
that you should not design your application well, you still could use some of REST principles in your application.
For example, stateless application simplifies scaling, REST-style URLs looks good for users and search engines, etc.
2.Yes, in truly REST all interactions should be expressed via standard verbs on resources.
But you could still create Transaction resource to wrap around your transaction.
See great discussion here: Transactions in REST?
3.As I understand nothing prevent you from providing metadata-information in HATEOAS-based response.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
GitHub API is great. It's quite convenient and simple at the same time.
It fits REST style at first sight. But does it actually? And why, if not?
Just to review, REST has certain properties that a developer should follow in order to make it RESTful:
What is REST?
According to wikipedia:
The REST architectural style describes the following six constraints
applied to the architecture, while leaving the implementation of the
individual components free to design:
Client–server: Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable.
Stateless: The client–server communication is further constrained by no client context being stored on the server between requests.
Cacheable: Responses must, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests.
Layered system: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches.
Code on demand (optional): Servers can temporarily extend or customize the functionality of a client by the transfer of executable code.
Uniform interface: The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. (i.e. HTTP GET, POST, PUT, PATCH, DELETE)
Does the API have those characteristics?
So, with all of this said, looking at the table of contents of the Github API docs that you linked to, I see, "verbs" which satisfies the uniform interface requirement, "endpoint", its served over api.github.com which means its a layered system, it offers some json-p callbacks which would satisfy the "code on demand" part, there is an "authentication" mechanism before using any verbs therefore it is stateless, it is presumably cacheable since that is typical of this type of architecture, and with all of this, you already have most of the characteristics of a REST API.
Yes. its RESTful enough to be called a REST API.
github: /repos/:username/:repo
other: /users/:username/repos/:repo - refer to:http://www.slideshare.net/apigee/restful-api-design-second-edition
I think it is RESTful Style.
But why github use first style?
Maybe RESTful is no standard.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have to use Amazon S3 to upload some static contents programmatically in Java.
When I started reading I found that the way to do is either through their SDK (wrapper over REST APIs) or using REST APIs. From Amazon's AWS website, found this:
"You can send requests to Amazon S3 using the REST API or the AWS SDK".
Wanted to understand that which approach is better. I think using SDK will definitely make programming easier, but what are the pros and cons of using SDK Vs Rest APIs directly.
For some reason, I found using REST API directly more difficult than SDK.
I was able to do basic things using SDk - create bucket, list objects, get object, invalidate cache etc.
But was having some hard time writing the code for REST API - especially generating the signature.
May be it will not matter much, if I ultimately use SDK, but I would still like to know how to do it using REST APIs. If anyone has some good code examples in Java on adding objects, get objects, get list etc, it would be very helpful.
Thanks!
If you already have the SDK in your language, go for it; it's a no-brainer from a project perspective. The SDK is additional engineering that they have already done and tested for you at no additional cost. In other words, the SDK is already converting the HTTP REST API into the application domain/language for you.
Think of the REST API as a the lowest common denominator that AWS must support and that the SDK (likely) as implementing the REST API below it. In some cases (eg: some Windows Azure SDKs), the SDKs are actually more efficient because they switch to a TCP based communications channel instead of REST (which is TCP plus HTTP), which eliminate some of the HTTP overhead
Unless your entire goal is to spend additional time (development + testing) just to learn the underlying REST API, I'd vote SDK.
In my own Opinion the API gives you room to do whatever you like.it also helps if you plan on changing a cloud service in the future but if the sdk approach is used, you will have to code again as your app will require a change and the SDK is embedded within your app. I know the response is late but it might help someone.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been unable to make a definitive choice and was hoping that somebody (or a combination of a couple of people) could point out the differences between using RestSharp versus ServiceStack's client services (keeping in mind that I am already using ServiceStack for my service). Here is what I have so far (differences only). The list is fairly small as they are indeed very similar:
ServiceStack
Pros
Fluent Validation from my already created service POCO objects
One API for both client and service
Code reads better (i.e. Get<>(), Post<>())
Cons
Some of my strings must be written out (i.e. If I make a GET request with query parameters, I must create that string in my code)
I must create a different class for each Request/Response Type (JsonServiceClient, XmlServiceClient)
RestSharp
Pros
Just about everything can be a POCO (i.e. If I make a GET request with query parameters, I just add the parameters via code)
Switching between Request/Response types is simple (request.RequestFormat = DataFormat.Json/Xml)
Cons
Manual Validation (beyond that found in the Data Annotations)
Two APIs to learn (this is minor since they are both fairly simple)
Code is not as readable at a glance (barely) (i.e. request.Method = Get/Post.. and main call is Execute< T >())
I was leaning towards RestSharp since it tends more towards straight POCO use and very little string manipulation, however I think ServiceStack might be acceptable to gain the validation and code that is more easily read.
So, here are the questions:
Which do you prefer?
Why the one over the other?
I know this is not a totally subjective question, but at bare minimum I am looking for the answer to this question (which is subjective):
Are any of my findings incorrect and/or are there any that I missed?
As the project lead of ServiceStack I can list some features of the ServiceStack Service clients:
The ServiceStack Service Clients are opinionated in consuming ServiceStack web services and its conventions. i.e. They have built-in support for structured validation and error handling as well as all clients implement the same interface so you can have the same unit test to be used as an integration test on each of the JSON, JSV, XML, SOAP and even Protobuf service clients - allowing you to easily change the endpoint/format your service uses without code-changes.
Basically if you're consuming ServiceStack web services I'd recommend using the ServiceStack clients which will allow you to re-use your DTOs you defined your web services with, giving you a typed API end-to-end.
If you're consuming a 3rd Party API I would recommend RestSharp which is a more general purpose REST client that is well suited for the task. Also as ServiceStack just returns clean DTOs over the wire it would also be easily consumable from RestSharp, which if you prefer its API is also a good option.
UPDATE - Using ServiceStack's HTTP Client Utils
ServiceStack now provides an alternative option for consuming 3rd Party APIs with its HTTP Client Util extension methods that provides DRY, readable API's around common HttpWebRequest access patterns, e.g:
List<GithubRepo> repos = "https://api.github.com/users/{0}/repos".Fmt(user)
.GetJsonFromUrl()
.FromJson<List<GithubRepo>>();
Url extensions
var url ="http://api.twitter.com/statuses/user_timeline.json?screen_name={0}"
.Fmt(name);
if (sinceId != null)
url = url.AddQueryParam("since_id", sinceId);
if (maxId != null)
url = url.AddQueryParam("max_id", maxId);
var tweets = url.GetJsonFromUrl()
.FromJson<List<Tweet>>();
Alternative Content-Type
var csv = "http://example.org/users.csv"
.GetStringFromUrl(acceptContentType:"text/csv");
More examples available from the HTTP Utils wiki page.