I am building an online portal for a client. I am in no way a professional coder/site builder, but do have some knowledge and experience with HTML and site building. The client owns multiple entities/companies in Delaware. The Delaware website has a site where you can search for these entities and it brings up a unique information page for each entity (https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx). In my portal I am trying to get an entity specific URL for each entity. Unfortunately, the URL in the address bar stays the same and doesn't show the unique URL for each entity.
Is there a way to find where in the inspect element or view page source where I can find the unique URL for a specific entity? So lets say I search for entity file number 5549973...when that page comes up, is there a way to find the link that would allow me to point to that specific page of information without having to go through the search again?
Related
Background:
I have a single page application that pulls data from a REST API. The API is designed such that the only URL necessary is the API root, ie https://example.com/api which provides URLs for other resources so that the client doesn't need to have any knowledge of how they are constructed.
API Design
The API has three main classes of data:
Module: Top level container
Category: A sub-container in a specific module
Resource: An item in a category
SPA Design
The app consuming the API has views for listing modules, viewing a particular module's details, and viewing a particular resource. The way the app works is it keeps all loaded data in a store. This store is persistent until the page is closed/refreshed.
The Problem:
My question is, if the user has navigated to a resource's detail view (example.com/resources/1/) and then they refresh the page, how do I load that particular resource without knowing its URL for the API?
Potential Solutions:
Hardcode URLs
Hardcoding the URLs would be fairly straightforward since I control both the API and the client, but I would really prefer to stick to a self describing API where the client doesn't need to know about the URLs.
Recursive Fetch
I could fetch the data recursively. For example, if the user requests a Resource with a particular ID, I could perform the following steps.
Fetch all the modules.
For each module, fetch its categories
Find the category that contains the requested resource and fetch the requested resource's details.
My concern with this is that I would be making a lot of unnecessary requests. If we have 100 modules but the user is only ever going to view 1 of them, we still make 100 requests to get the categories in each module.
Descriptive URLs
If I nested URLs like example.com/modules/123/categories/456/resources/789/, then I could do 3 simple lookups since I could avoid searching through the received data. The issue with this approach is that the URLs quickly become unwieldy, especially if I also wanted to include a slug for each resource. However, since this approach allows me to avoid hardcoding URLs and avoid making unnecessary network requests, it is currently my preferred option.
Notes:
I control both the client application and the API, so I can make changes in either place.
I am open to redesigning the API if necessary
Any ideas for how to address this issue would by greatly appreciated.
Expanding on my comment in an answer.
I think this is a very common problem and one I've struggled with myself. I don't think Nicholas Shanks's answer truly solves this.
This section in particular I take some issues with:
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The implication I take from this, is that urls on your application are only valid for the life-time of the history file or disk cache, and cannot be shared with other users.
If that is good enough for your use-case, then this is probably the simplest, but I feel that there's a lot of cases where this is not true. The most obvious one indeed being the ability to share urls from the frontend-application.
To solve this, I would sum the issue up as:
You need to be able to statelessly map a url from a frontend to an API
The simplest, but incorrect way might simply be to map a API url such as:
http://api.example.org/resources/1
Directly to url such as:
http://frontend.example.org/resources/1
The issue I have with this, is that there's an implication that /resource/1 is taken from the frontend url and just added on to the api url. This is not something we're supposed to do, because it means we can't really evolve this api. If the server decides to link to a different server for example, the urls break.
Another option is that you generate uris such as:
http://frontend.example.org/http://api.example.org/resources/1
http://frontend.example.org/?uri=http://api.example.org/resources/1
I personally don't think this is too crazy. It does mean that the frontend needs to be able to load that uri and figure out what 'view' to load for the backend uri.
A third possibility is that you add another api that can:
Generate short strings that the frontend can use as unique ids (http://frontend.example.org/[short-string])
This api would return some document to the frontend that informs what view to load and what the (last known) API uri was.
None of these ideas sound super great to me. I want a better solution to this problem, but these are things I came up with as I was contemplating this.
Super curious if there's better ideas out there!
The current URL that the user is viewing, and the steps it took to get to the current place, are both application state (in the HATEOAS sense).
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The starting point of the API is (well, can be) compiled-in to your client. Commpiled-in URLs are what couple the client to the server, not URLs that the user has visited during use of the client, including the current URL.
Your question, "For example, if the user requests a Resource with a particular ID", indicates that you have not grasped the decoupling that HATEOAS provides.
The user NEVER asks for a resource with such-and-such an ID. The user can click a link to get a query form, and then the server provides a form that generates requests to /collection/{id}. (In HTML, this is only possible for query strings, not path components, but other hypermedia formats don't have this limitation).
When the user submits the form with the ID number in the field, the client can build the request URL from the data supplied by the server+user.
Given the following scenario:
a RESTful API
that RESTful API has permissions/authorizations that can be granted to entire entity collections, and/or to particular entities, i.e. complex role based permission rules.
The API is (according to RESTful principles) HATEOS-driven (resource url's are revealed through the API. Once you login and get back the "user" resource, you are able to drive the entire API through links given in responses.
A front-end client (web app) that needs to use this API
Imagine now the front-end wants to build a menu. That menu is based on access to particular entities and/or entity collections. For example an "Administration" menu will be shown if the user has access to one of a number of different entities and/or collections.
How do I build the menu? I need to know the permissions the user has in order to build the menu propertly. I don't know all the permissions the user has because it would require walking the url's of the REST API to see all the objects the user has permissions on.
This seems like a tough thing to overcome, but maybe I am missing some obvious technique. How can this impedance mismatch overcome?
Your REST API can expose a resource (or it can be a part of the user resource returned after a user has been successfully signed in) which will contain information what resources the user can access and therefore what menu items should be available for this user.
By RESTful best services there is the HATEOAS principle which told us that we should not allow the client to build resource URL-s. If we follow this principle, it will be pretty hard to share the current state of the client. For example if you have a REST service on the server, and you gets data via AJAX with a single page javascript client, then you will have 2 urls. One for the client state, and one for the result you got from the REST service. You can share only the client state with the use due to pushState... If somebody runs the client with a previously shared url, then her client won't know about the url of the REST service it should call, because the client cannot build URL-s, just receive from the REST service and utilize it.
For example:
I browse the http://my.client.com
the page gets the root resource from the http://my.api.com, and return a link
the link contains the http://my.api.com/users url, with rel user collection
after that the client displays a button with label: userlist
I click on that button, the client get the data from the api, and prints the user list
if I want to share the user list with my girlfriend, then I have to change the browser url from the client with pushState, for example from http://my.client.com to http://my.client.com/users
after that I send that url to my girlfriend
she copy-pastes that into her browsers address bar and presses enter. after that the client says a huge wtf, because - like John Snow - it knows nothing about what state that url means...
This problem can be solved, if we allow the client to build GET http://my.api.com/users from the url: http://my.client.com/users, but this won't be RESTful, because the client should not build api urls...
If I want to display a nested menu in the client, then that is another problem, because I don't want to send the whole menu tree in every answer. I could create a menu projection for every resource, or use the OPTIONS method, or a custom method to send that data, but that would be a pain in the back. This can be solved by following the rel=up links - got from the REST service - in series, but if I don't know from where should I follow, it will not work...
This problem occurs by google bots too...
How can I both solve this problem, and stay inside the boundaries of the HATEOAS principle?
Normally we don't want to share all of that information with anybody, so we cannot export all of that just the current page we are in.
There is nothing wrong with storing the whole resource on the client and then pushing it up to the server to change the state on the server. If you are worried your resources are getting too large though you could break the resources out a bit. So say you have an order resource and that needs to associate with an address. You don't need to put the address in the order resource, just a link to the address to use. The user can add or alter that address independently. So you might have something like
www.myapi.com/users/1234/shippingaddresses/default
And the client can PUT a new address to this resource. Then in the body of the order resource you can have a link to this resource
POST www.myapi.com/users/1234/orders
{
...order information...
"shipping_address": "www.myapi.com/users/1234/shippingaddresses/default"
}
To be RESTful the client should not build that URL, it should have been given it by the server at some point in the recent past, possibly when the users is selecting which address to use. For example, in the previous step the client could have requested all addresses
GET www.myapi.com/users/1234/shippingaddresses
And presented the list of addresses to the user in a drop down list.
I'm building a API Centric web application but I'm having trouble wrapping my head around some of the business logic.
Take this Use Case:
POST /companies -> User adds a new Company which has a Location
(Company Entity has a Location Entity which keeps the address of the company, A Company has one Location, a location can have multiple Companies)
PATCH/PUT /companies/{id} -> User edits a Company information (changes street name from Company->Location
I want my API to be able to check if there are already other companies on that Location.
If this is the case, I want the user the chose between editing the Location Entity (which will change then for all Companies on that Location) or create a new Location.
How do I send this choice back to the User in a RESTful manner?
easy :
PUT replace the entire resource if it exists or create a new resource if it doesnt exist. there is no choice to be made if you want to stay strictly REST( but you dont have to) .it's up to your users to check if the company exists with a GET before a put.
POST is suppose to replaced all the companies collection.
You could use PATCH however to update an existing company.
see : https://www.rfc-editor.org/rfc/rfc5789
The REST API or any strict service would provide a response based on a request. So the REST API can definitely respond back to the user if other companies are related to the location. But there is no way for the API to respond back with a choice. The API can respond back with some information and the user will need to make another request based on that information.
Instead, it is better to give the user the option to specify it upfront. So, the choice of whether related companies should be updated for the location is made upfront by the user as par of the request. For example, the user can specify this as a query param on the REST API and the service can take appropriate action based on that query param.
All,
I need to create an app for work that signs into our website using SSL and returns our member information.
I have figured out how to log in but am not sure how to find the id tags that I want to bring into my app and store to be show in a table view.
I know how to do these three things.
Put in username and password,
authenticate against website,
create session cookie.
Not sure how to do these things.
Get information about member, ie, how long a member , sustaining member, ect from the website knowing the tags for these fields on the site.
Store the data (core data?) or flat file. Shouldn't be that much information.
Format and present data in table view.
Lots of information here about getting files or whole websites but not so much about picking information off websites for concise viewing.
Thanks.
If your company's site is designed to provide this information through a web service, then it should be as simple as constructing your request URLs appropriately. If it has not been designed to interact with anything but humans, then you're probably going to have to do a great deal of work parsing HTML which no one can really help you with unless said site is publicly accessible.
Web Services should work fine with our website.