I was asked "how do you call restful api in angular2 server" in a front end interview before. I said using the http. But interviewer didn't seem satisfied with this answer. What is the correct answer? Thank you!!
I was asked the same question in almost every interview I had, such as
How do you consume Restful web services in Angular 2/4
How do you create RESTful Webservice? and couple other such as
REST vs SOAP, etc.
Since I worked on Angular 2/4 and RESTful web services, I know the story about how they work. So rather than just answering "using Http protocol" I would elaborate on the answer by mentioning
The HttpClient in #angular/common/http offers a simplified client HTTP API for Angular applications
How you call the CRUD operations from service.ts file, use of observables and subscribe() method in component.ts file. (the component subscribes to the method's return value)
https://angular.io/guide/http . - more info
The 5 types of Http methods or for CRUD operations we use like
HTTP GET, POST, PUT, DELETE, PATCH and their functionality,
https://restfulapi.net/http-methods/
The way we use Postman collections (in my case) to test REST API calls or Swagger, etc. The format the data gets processed ( in this case of REST its JSON ). (JSON importance if necessary)
Please comment if you find any other reference or better points to answer coz I am learning too.
Related
I am a bit confused about the difference between the two.
What I have been making till now is just deploying a web application that gets invoked by a URL and returns a response(json/XML) .
what I have read about rest web services
Its a way to communicate with web applications and to reveal your methods to the world.
Question 1
But in my case I did the same revealing the URL .
Platform independent
The rest features say that its Language-independent (C# can talk to Java)
Question 2
But in traditional approach also any language can invoke any web service by simple request (get/post) which ever implemented.
Question 3
What is rest and how to get started with it (specifically in terms of django) if possible.?
You are doing REST.
REST is not a library, or a format, it's simply a technique. What you call the "traditional approach" is exactly what REST is: simple requests via GET and POST (as well as PUT and DELETE) to an endpoint that returns JSON or XML.
That is in contrast to the previously-dominant way of making API requests, ie SOAP, which requires all sorts of up-front configuration of WSDL files and service discovery, along with particularly specified request formats.
Thanks for looking!
Background
I am building a strictly machine-to-machine web-service (restful) application. The application will listen for requests, retrieve data, construct objects, serialize to JSON and return the JSON object.
This application will ultimately be used by other web applications as well as iOS apps, Android apps, and even desktop apps.
The existing code that I have inherited makes a distinction based on how the service was called in terms of HTTP verbs (GET, POST, etc).
Question
In this day and age of machine-to-machine communication, is the HTTP verb even relevant any longer? Could it in fact be constraining for future adoption of the service API to base the code around HTTP verbs?
Update
fmgp provides a clear answer to "why" these verbs are used, but I feel should I clarify my concern:
Will other platforms such as iOS or Android (for example) be able to originate HTTP verb-based calls like GET and POST? If the answer is "no" then I assume that we should stay away from relying on these verbs and instead build the desired action into the request URL as a parameter.
In RestFul applications, you have a verb foreach CRUD operation:
Create: POST
Read: GET
Update: PUT
Delete: DELETE
Everything claimed "restful" will work the same way according to this philosophy.
There's nothing standard in that, just a clean, good designed, easy to understand programming style. Of course you may want to do all operation with only GET and some query parameters as soon as your client and server can handle it.
I am new to Enyo and web services. I am looking to build a web page with Enyo that will require use of Echonest. Can anyone help me understand how to connect to the Echonest service from inside Enyo and whether to use SOAP, REST, or something else?
I assume you are talking about the Echo Nest found here: http://the.echonest.com ?
Briefly glancing at their API, you may not have to use SOAP or REST since everything is accessible with simple GET requests through the Web service. It looks like the hardest part of using their API will be generating OAuth signatures for authenticated requests.
As far as the enyo.WebService, http://enyojs.com/api/#enyo.WebService, goes, you should be able to include the kind, set the URL and call the .send() method on it. Then you response handler would get the data back (I recommend json) so you can do what you will with it.
Another option would be to use enyo.Ajax, http://enyojs.com/api/#enyo.Ajax, directly. enyo.WebService wraps that and provides a familiar (to Enyo 1 developers) way to use it.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What exactly is RESTful programming?
What are RESTful web services? What would be an example of it?
What is the difference between the asmx web services and the WCF RESTful service?
REST is a client-server architecture which (among other things) leverages the full capacity of the HTTP protocol.
Some relevant points in REST:
Each URL on the server represents a resource; either a collection resource or an element resource.
A collection resource would be available at a URL like http://restful.ex/items/ which would be a representation of a list of items.
A element resource would be available at a URL like http://restful.ex/items/2 which would be a representation of a single item, identified by 2.
Different HTTP methods are used for different CRUD operations:
a GET is a read operation
a PUT is a write/modify operation
a POST is a create/new operation
a DELETE is a... ok, that one is kind of self-explanatory.
State (or rather, client context) is not stored on the server-side; all state is in the representations passed back and forth by the client's requests and the server's responses.
You can check out Roy Fielding's (the creator of the REST architectural style) wiki page here and then move on to his PhD dissertation here and finally for a quick example just take a look at the Twitter API.
It's basically web services that implement CRUD using the HTTP methods(GET, POST, PUT, DELETE)
RESTful webservices use HTTP methods explicitly by mapping the REST operations to HTTP methods:
Create - POST
Retrieve - GET
Update - PUT
Delete - DELETE
Here is a link to a good summary.
Check description of REST. Web services conforming to this principle are called RESTful.
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers