I am developing mobile application and now I'm preparing server API.
There will be search bar and user will be able to search other people by using mutliselects, inputs (just like web form).
And now the question is - what type of HTTP request is the most appropriate to send parametrized request to the server (using cURL) and get friends list as response?
I am thinking of using GET, but user will be able to set multiple values for one argument:
state - user can select more than one state
So I thought that using POST with request body in JSON format will be the best.
{"states":["state1", "state2", "state3", ...]}
But reffering to https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p2-semantics-16#section-7.5:
POST is designed to allow a uniform method to cover
the following functions:
o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles;
Can anyone advise what type of query should I use?
You can send multi-dimensional data in URLs like:
http://g.com/p.php?arr[]=1&arr[]=2
See:
AngularJS - How to send multidimensional $http.get() data
For another example.
Related
Link to the HATEOAS This is the link to the Hateoas article (snapshot below) where the identifiers of the resource is part of the URL i.e. 12345. Here the API response has the final API relative URL i.e. /accounts/12345/deposit and the client just needs to hit it.
Link to the Github Users API This is the link to the Github API (snapshot below) where there are lots of placeholders for identifiers. How will clients modify these URLSs and add a value in these placeholders? For example, {/gist_id}, {/other_user}.
Isn't passing the URL with id value instead of placeholder better? Why and when to rely on different clients to add values in these placeholders?
Hypertext as the engine of application state (HATEOAS) is a bit more than just the usage of links. In essence it enforces the interaction model that is used on the Web for two decades quite successfully. On the web a server usually "teaches" clients (browsers) to achieve something via the help of link relations, that can be used to automatically download related resources or give a hint on the reference resource, and Web forms, that define the syntax and semantics of each of the respective supported (input) elements, i.e. a text field, an option element to select one or multiple choices, a drop down or even a slider widget. Based on the affordance of each of the elements a client knows i.e. that a button wants to be clicked or pressed while a text fields wants some user input and stuff or a link annotated with the prefetch link relation name may be downloaded automatically once the current page finished loading as a client might invoke it next or a preload link relation might instruct a user agent to load the referenced resource early in the current page loading process.
The form not only teaches a client about the supported fields a resource has but also about the target URI to send the request to, the HTTP method to use wile sending the request as well as the media-type, which in the case of Web forms is usually implicitly set to application/x-www-form-urlencoded.
In an ideal world a client just uses the information given by the server. Unfortunately, the world isn't perfect and over time people have come up with plenty of other solutions. Among one of them is URI templating that basically allows clients to use a basic URI and fill out certain placeholders with concrete values. As making use of templating requires some knowledge of the URIs intention or the parameters you need to pass, such capabilities make only sense as part of media-type support.
Plain JSON (application/json) has by default no support for URIs whatsoever and as such a user agent receiving a plain JSON payload might not be able to automatically replace a template URI with a concrete one out of the box. JSON Hyper-Schema (application/schema+json) attempts to add link and URI template support to plain JSON payloads. A user client though needs to be hinted with the appropriate media-type in order to automatically resolve the full URI. As such, the user agent also has to support that respective media type otherwise it won't be able to process the document (resolve the template URI to a real URI) successfully.
JSON Hypertext Application Language a.k.a HAL JSON also supports URI templates for links. application/collection+json does support two kinds of templates - query templates and objects-template. The primer one is similar to a URI template by allowing to append certain query parameters to the target URI upon sending the request while the latter one allows to define a whole object that contains all the input elements used to add or edit an item within the collection. JSON-LD does not really support URI templating AFAIK though it uses the concept of a so called context where certain terms can be used to abbreviate URIs. As such something like name can be used within the context for a URI like http://schema.org/name.
As you can hopefully see, the support for URI templating depends on the media-type used for exchanging data. In the case of the outlined github example GET /users/:username this more or less resembles a typical Web API documentation, similar as it is done in a Swagger API documentation, that unfortunately has hardly anything to do with HATEOAS.
For your top example (banking), you should absolutely include the complete URL, with account numbers (IDs), so that the client does not need to translate/substitute anything. This is the most common scenario with HATEOAS. However, GitHub does have those "placeholders" for endpoints that could contain multiple values. You can't include the "following_url" for every user in the response, it's not practical. So you have to determine the "other_user" value another way and make the substitution. Personally, I haven't even had this use case with any of my applications and all of my HATEOAS URLs resemble you first example (though I prefer full URLs not relative). Unless you have specific cases like GitHub does, it's not necessary to use any of these placeholders. Even GitHub only uses that where they could be multiple values. For fixed value URLs, they have the username (like your account number) in the URL ("octocat").
According to me we should not give the direct url in the body
We should always parameterized the api and get details form there.
In simple case if Id of data change than every time data need to update for detail url.
Else if it’s dynamic you will never face this issue.
And this also come under best practices.
I have been using Infusionsoft form embedded in html page but now I want to send data to Infusionsoft form using their API. I checked their APIs but could not figure out which one should be used to submit data to the Infusionsoft form. Can someone please help me with this?
https://developer.infusionsoft.com/docs/xml-rpc/
Thanks for looking into this.
Thank you, Naresh
Try to use REST API instead of XML RPC. Developer center already marked XML RPC to "legacy" module, and I guess they will replace "XML RPC" sooner or later.
Regarding to your question, you will need to define what data set you want to update.
For example, if your form is going to insert a new contact, you will need 2 things from your code.
First, prepare the parameters such like "email_addresses", "phone_numbers" and "given_name".
Second, POST request with parameters to this URL "https://api.infusionsoft.com/crm/rest/v1/contact?access_token=123abc" after authentication.
Ways to test:
Try REST API calls on page https://developer.infusionsoft.com/docs/rest/
Good luck.
To pull Webformvia API you will have to use following method, this will pull the HTML form:
Retrieve a Form's HTML
to submit a data to Infusionsoft via API
You will have to use Create contact and update contact API:
Create Contact
Update COntact
XML RPC is still in use but Infusionsoft suggests to use REST API methods
Create a Contact
Update a Contact
Single API call for two methods: Create or Update a Contact
TL;DR How to mix REST requests with some non-REST requests in SPA(frontend/backend)? Or might be I just get REST wrong?
We are planning new API for SPA and mobiles(plus probably some 3rd parties). There will be some requests which, I suppose, can't be covered by REST.
I am speaking mostly about requests which would make backend do something, which would modify state of document or give some additional info, based on document, but request itself is rather simplistic.
Here is really easy example. I want to add a comment to blog post. For example I might do it like this:
Create comment. POST /comment
Create connection between author and comment. POST /comment_author or PUT /comment with author_id.
Create connection between comment and post. POST /comment_post or PUT /comment with post_id.
I also could do something like POST /comment with {author_id, post_id} which actually seems most logical here.
Everything did work, comment added to blogpost and associated with author.
Now customer wants to get statistics for his comment, like words stats and letters stats. As a part of request I pass comment_id. Backend might update comment with stats data, it might create separate entity and link it with comment or it might just send me those stats for this comment without saving.
So what would be the choices?
I can do something like:
GET/PUT /comment/:id/stats. For me it seems already hack, because as a result I don't want a document of type comment, but document of different type. As well as I don't send stats with request, I calculate them on backend so using PUT seems wrong.
POST/GET /comment_stats/:comment_id. Seems legit, but if I don't have a document/entity of type comment_stats, that would mean that I actually ask backend to create something, backend would reply me OK/Created, but actually I don't have this document somewhere saved.
So, while I understand REST != CRUD, I thought to use REST for simple CRUD and, for cases like that, to use RPC. So in RPC scenario I would just call POST comment.stats(comment_id)
My questions are what would be better choice in this situation, as well as are my thoughts about rest/rpc right?
I would go with GET /comment_stats/:comment_id for proper separation of concerns, so that report code doesn't clutter the comment resource.
It doesn't matter if you don't actually have a comment_stats document, or how the data is represented on your backend. The REST API is just an abstraction over your backend.
In general, for any non-CRUD action like this, it's better anyway to create a new resource and deal with it as if it was a "machine": you send some instructions to the machine (via a GET or POST call). The machine executes it and then returns the result. A simple example would be an endpoint to convert images: you create an /image_converter end point (the machine), you POST an image to it, it converts it, and sends back the image. /image_converter would have no associated entity/document in the database but for the end user it's still a resource with a logical behavior.
We are attempting to get site logos from the Yodlee API. From the SiteInfo data model (using the SOAP API), there are the following methods that appear to retrieve site logos
siteInfo.getDefaultSiteLogo()
siteInfo.getLocalizedSiteLogos()
getDefaultFavIcon()
The issue is that these methods for the sites we are using (all sites with the AU geography) are returning null.
I am pretty sure this is possible to do, since Yodlee's own fastlink does show logos for sites as you are adding them.
Here are the method call signatures
I am using the soap api through java (using axis 1.4, just like in the sample code) and the API signatures are as follows
SiteAccountManagementService has the method getAllSiteAccounts which has the following signature
com.yodlee.soap.collections.core.accountmanagement.ArrayOfSiteAccountInfo getAllSiteAccounts(com.yodlee.soap.common.UserContext userContext).
Then there is also getCctx, which has the following signature
public com.yodlee.soap.common.CobrandContext getCctx()
None of these methods have a request specifier parameter of any sought
I don't think icons will be returned by default. I believe you need to specify this in your request specifier to get icons/image.
getAllSiteAccounts API is to get the details for the Accounts aggregated by a consumer,
while the information you are looking for(the Logos) are site related not consumer related.
You should use getSiteInfo(under SiteTraversal) to get this specific detail and remember to pass value of siteFilter.reqSpecifier as 128.
How can code be resource?
I will give you an example: I want to create a hotel web site. But also i want to show my customers, which come from abroad, at which time they can come to my city. So i deal with an airplane web site. This site will give me his resources using REST. (resources mean representation of resources). For example his URI will be like that http://example.com/plane/flight%5Fnumber http://example.com/plane/flight%5Fnumber/date
My users will give me a date and i will say them at which flight number they can come. I'll give him a list of flight number then he can fly. OK. there is something i haven't solve yet. if i would know the plane number, i found date. But i dont know which flight number can he travel. So i need to search all the plane and all the flight number to find the same date. But how can i do it? How can i write my query?
another question is I have a function. That function gives me the flight number if i give the date [ int get_Flight_Number(12/11/2009) ].
I just want that clients can see parameters and name of function. And I want him to use my function. How this will be happen?
Without the details of the media types returned by the service it is difficult to answer your question. Does the site return a search form? Does the site return a collection of flights for a set of dates?
The general flow of any http based RESTful client inquiry should go something like this:
Do a HTTP GET on the root url of the
API.
Parse the response based on the
media type specified in the http header "Content-Type".
Does the response contain the answer
to my question?
If yes then extract the information
and do what you want with it.
If no, then does the response
contain a link to another resource
that may have the answer to my
question.
If yes then do a HTTP GET or POST on
that link based on what the media
type definition tells you to do. Goto step 3.
If no then stop looking and tell the
user you cannot find an answer.