►
Description
More details on the covered content in this webcast from http://dev.office.com/blogs
B
A
We
kind
of
covered
through
the
different
options
and
different
kind
of
approaches
of
getting
the
data
from
SharePoint,
so
you
might
be
familiar
of
getting
the
data
using
raw
restore.
You
might
come
from
a
butts,
a
classic
ship
ones
background
so
you're,
familiar
of
using
Java
Script
object
model
in
the
context
of
SharePoint
and
the
really
the
purpose
of
this
webcast
is
kind
of
shows.
The
difference
is:
what's
the
advantage
of
using
a
different
option
and
we
walk
through
the
JavaScript
object
model
raw
rest
operations.
A
They
say,
they'd,
be
a
risk
approaches
in
SharePoint
framework
and
also
SharePoint
javascriptcore,
compare
log
library
which
is
coming
from
the
BMP
initiative.
So
we
will
have
a
a
walkthrough
of
different
options
in
slides
first,
actually
at
a
once
line
and
then
Wallach
is
going
to
do
a
live
demo
on
the
differences
as
well
before
we
go
to
the
actual
contents.
It's
quickly
explaining
SharePoint
potential
breakfast
is
a
open
source
initiative
which
is
coordinated
by
the
SharePoint
engineering,
but
we
work
together
with
community.
A
So
all
of
the
stuff
that
we
are
contributing
is
dependent
on
the
contributions
of
the
community
as
well,
and
one
of
the
benefits
out
of
that
one
is
that
these
are
real
world
learnings
as
well.
So
whenever
somebody
is
hitting
or
solving
issues
with
customers,
we
can
actually
share
them
through
the
SharePoint
B&B
for
others
in
a
community,
and
everybody
can
benefit
out
of
those
learnings
as
well.
The
SharePoint
PNP
provides
code
samples,
guidance,
documentation.
We
have
open
community
calls
actually
a
weekly
basis
and
a
monthly
cost
and
bi-weekly
special
interest
group
calls.
A
Then
we
have
case
studies
available.
There
is
our
on
share
framework
sharepoint,
that
in
microsoft,
cry
office,
365
in
general,
and
everything
in
the
sharepoint
about
not
everything
but
mature.
Some
of
the
areas
in
the
sharepoint,
which
are
suitable,
absolutely
applies
to
own
premises
as
well
sharepoint
framework,
as
an
example,
will
land
on
on-premises
the
sharepoint
2016
during
calendar
year
of
2017.
So
if
you
learned
leadership
on
framework
now
in
sharepoint
online,
it
will
be
then
user
going
on
the
premises
and
later
this
year,
depending
obviously
on
which
year
you're
watching
this
video.
A
Now
we
introduced
the
SharePoint
objects
at
sorry,
javascript
object
model,
javascript
object
model
was
introduced
in
SharePoint
2010,
so
it's
pretty
little
already
and
it's
kind
of
an
implemented
in
a
classic
JavaScript
way.
It
mimics
heavily
client-side
object
model
from
an
operation
perspective
and
it
works
with
delegates.
So
that's
kind
of
a
big
difference
on
us.
Let's
say
a
modern
web
stack
development
model.
It
does
not
support
promises
which
could
be
a
massive
deal
when
you're
implementing
your
implementation
or
a
client-side
web
bar,
and
it's
there's
no
investments.
A
What
we're
doing
this
one
anymore
from
an
engineering
perspective.
So
it's
absolutely
supported
we're
not
going
to
take
that
away,
but
it's
we're
not
investing
heavily
on
the
JavaScript
object
model
for
time
being,
then,
for
all
of
these
options
like
we
started
with
javascript
object
models.
We
have
these
three
different,
let's
say
aspects
which
were
kind
of
a
rating
as
well,
because
we
are
no
longer
investing
on
javascript
object
model.
We
don't
consider
that
really
as
a
future
provement.
That's
why
there's
an
exclamation
mark
on
that
section.
The
coverage
for
JSON
is
fair.
A
It's
not
actually
that
big.
If
we
compare
that
to
do
all
of
the
rest,
API
sand,
which
are
available
within
SharePoint
and
the
ease
of
use
is
actually
hard,
especially
considering
SharePoint
framework
and
deployment.
If
you,
if
you
do
a
let's
say
scripted
at
a
web
part
and
you
block
in
your
JavaScript
there,
somebody
might
orbital
say
there's
no,
no,
that's
not
hard.
A
That's
super
easy,
also
scared
to
do
let's
say
Google
or
Bing
and
copy
I
find
the
relevant
JavaScript
and
just
pasted
it
in,
but
that
sounds
necessarily
really
future
proof
for
your
customization
and
it
might
not
be
considered
that
they
would
say
a
controlled
way
of
doing
development
as
well.
Anything
one
acts
out
like
on
this
one
yeah.
B
So
I'm
Jason
in
order
to
reuse
that
you
have
to
load
a
few
scripts
and
the
trick
is
that
you
have
to
load
them
in
the
right
order
or
things
will
break.
So
that's
the
one
thing
that
to
some
degree,
depending
on
what
you
wanted
to
use,
was
done
already
for
you
in
the
past,
but
on
the
modern
side
with
SPF
X.
You
have
to
do
all
of
that
by
yourself,
because
Jason
is
not
available
already
on
a
page,
so
you
have
to
load
it
by
yourself
and
you
have
to
do
it
correctly.
B
Then.
Another
thing
that
she
hesitated
take
into
account
is
that
the
way
Jason
works,
as
we
said,
is
mimic
see
he
sees
he
some
right.
So
you
have
to
work
with
the
context.
You
have
to
work
with
queries
and
there
is,
if
you
work
with
another
API,
let's
say
based
on
rest,
then
there
is
no
reference
of
for
you,
because
Jason
works
in
in
a
unique
way.
So
you
have
to
learn
that
API
in
order
in
order
to
use
it.
So
you
cannot.
B
You
cannot
benefit
of
anything
that
you've
learned
elsewhere,
because
that
API
is
unique.
If
you
will
Church
showed
that
that's
what
we
said,
that
it
is
hard
and
also
there
are
some
quirks
which
you
will
see
in
in
a
demo
like,
for
example,
if
you
want
to
load
live,
not
the
whole
list,
only
part
of
it,
then
there
are
some
tricks
that
you
have
to
know
and
it's
not
easy
to
find
how
it
all
works.
So
with
that,
it's
quite
hard,
comparing
to
other
approaches
that
are
available
to
you
absolutely.
A
So
then,
I
think
the
key
point.
What
to
say
is
the
fact
that
it's
a
unique
API.
It's
not
consistent.
It's
not
consistent
of
anything
what's
out
there
and
it's
really
really,
and
obviously
we
should
have
done
a
better
job
for
my
documentation
perspective
for
this
one,
which
could
be
one
of
the
reasons
why
it's
super
super
hard
to
use
and
one
of
the
things
actually
on
the
JavaScript
object.
A
The
advantages,
no
doubt
is
that
it's
the
same
across
technology
stacks.
So
it
doesn't
matter.
You
have
writing
dotnet
code
or
JavaScript
or
nodejs
operations.
The
way
to
use
the
REST
API
it's
exactly
the
same.
It
is
super
easy
for
getting
requests
because
you
just
keep
the
get
request
and
then
you're
good
to
go.
But
it's
actually
super
complex
for
nun
gets
requests
because
you
need
to
figure
out
all
of
the
additional
plumbing.
A
You
need
to
get
the
form
digest
and
everything
else
and
do
the
hitters
and
and
chasing
objects,
and
all
that
within
your
code,
roll
res,
no
doubt
is
an
ever
queen
because
well
there's
it
is
the
endpoint
on
the
other
side
of
the
SharePoint
and
but
then
there
is
the
additional
complex
and
it
is
a
future-proof
which
is
kind
of
understandable.
The
coverage
is
excellent
because,
obviously,
which
will
risk
everything
every
single
REST
API
is
available
for
you
to
him.
A
So
it's
not
a
library
as
such
now
like
mission,
but
all
of
the
areas
which
were
releasing
are
essentially
available
for
you
to
take
both
take
into
use
and
no
doubt
maybe
a
small
slight
trip,
a
sidestep.
Yes,
we
are
working
on
a
better
code,
documentation
or
our
REST
API
as
well,
which
no
doubt
should
be
there
easier.
If
you
it's
moderate,
it's
not
super
easy,
but
it's
not
super
hard,
especially
if
you're
getting
the
information
from
SharePoint
site.
Anything
of
1ry
like
on
this
one.
B
I
would
stress
few
things
right.
So,
first
of
all
is
that,
as
you
use,
you
said
it
works
exactly
the
same
across
stacks.
So,
no
matter,
if
you
build
phone,
apps,
OS,
app
or
web
app,
it
will
work
exactly
the
same
everywhere
because
it
just
rests
right.
You,
you
just
issue
a
web
request
and
you
get
a
response
and
it
is
exactly
the
same
everywhere.
B
Another
thing
is
that,
as
you
said,
it
easy
for
get
request
bars
beyond
that.
It's
challenging
right
because
for
a
post
or
a
booth,
you
have
to
know
exactly
the
objects
that
you
have
to
send
and
they
are
not
always
trivial
right.
So
that
that's
one
thing
and
another
thing
is:
if
you
would
like
to
batch
the
requests
it
is
supported
and
there
is
ways
to
do
it,
but
it's
not
fiddle
as
well
right,
because
it's
a
response
that
you
get
spends
multiple
requests
and
you
have
to
parse
all
of
that
by
yourself
right.
B
A
True,
no
doubt
so
natively
in
SharePoint
framework,
then,
because,
although
that
the
raw
rest
is
is
like
well
except
it
is
a
labor
intensive.
We
wanted
to
help
on
making
things
happen
more
easily
and
in
SharePoint
frameworks
there
is
an
SBS
2d,
big
client,
which
is
essentially
making
the
operations
and
REST
API
calls
more
easily
available
for
photo
developers.
This
is
a
SharePoint
framework,
specific
implementation.
A
So,
if,
if
it's
well,
you
can
access
the
API
from
the
SharePoint
framework
libraries,
it's
easy
for
all
kinds
of
requests,
so
you
can
actually
more
easily
handle
well
takes
care
of
the
plumbing.
For
you
for
many
of
the
complexity,
for
example,
in
post
operation
and
for
non
gate,
operation
you'll
still
need
to
create
the
Chasen
object,
which
is
understandable.
So
you
need
to
go
and
have
a
look
on
to
the
object
structure
itself.
A
What
I've
actually
posting
to
what
SharePoint
that
the
the
REST
API
knows,
then
how
well
handle
the
incoming
messages
and
if
they,
between
the
SharePoint
framework,
absolutely
sever
Queen
as
well.
The
coverage
is
excellent
because,
again
both
well.
It
is
exactly
the
same
coverage
as
with
the
row
rest,
and
what
we're
essentially
doing
is
that
we
are
doing
making
the
plumbing
to
happen
in
a
hidden
way.
They
don't
need
to
worry
about
that.
A
One
and
ease-of-use
is
kind
of
at
rated
as
moderate-plus,
essentially
easier
than
risk
a
row
list,
but
it's
not
super
super
easy
either,
because
every
now
and
then
you
need
to
still
build,
for
example,
just
chasing
objects.
You
need
to
have
a
look
on
the
structure
and
also
anything
one
out
on
this.
One.
B
I
think
that
the
one
way
you
could
see
it
is
that
it
is
a
wrapper
around
row
rest,
so
you
still
work
with
URLs.
You
still
write
exactly
the
endpoints
that
you
want
to
hit.
You
still
still
construct
using
the
objects
for
post
and
and
put
for.
There
are
a
few
prerequisites
that
you
don't
need
to
worry
about
them
yourself.
So
that's
why
using
the
SP
HTTP
client
is
easier
than
working
with
the
raw
rest.
Absolutely
absolutely.
A
And
then
the
the
final
piece
of
the
puzzle
or,
let's
say
an
option.
Obviously
it's
debatable.
It
is
only
four
options.
There's
multiple
other
other
libraries
out
there
as
well,
but
one
of
the
things
which
will
actually
sleep
a
crowd,
and
we
want
to
raise
that
in
these
discussions
as
well
is
the
community
treatment,
the
MBTA's
core
and
because
this
is
actually
super
super
easily
poachable
API
for
accessing
the
information
within
a
within
SharePoint.
A
It
is
a
fluent
API,
so
you're
able
to
do
stuff
like
B&B,
got,
wet
dot,
lists,
dot
fields
and
you
actually
get
access
on
the
on
the
field,
since
you
don't
have
to
explicitly
do
the
rest
operation.
So
all
that
complexity
is
hidden
under
the
covers,
so
you
can
just
access
you.
You
get
a
objects
which
you
can
then
manipulate
and
get
access
to
the
data
and
it
works
natively
with
promises
with
the
big
thing
overlay
as
well.
You
don't
have
to
do
anything
any
additional,
compare
implementation
on
them.
A
It
is
an
open-source
community
even
initiative.
So
this
is
not
something
what
SharePoint
framework
and
SharePoint
engineering
is
pushing
out.
This
is
an
open
source
at
initiative,
obviously,
from
a
user's
perspective.
This
is
a
great
tool
to
be
used
in
a
closer,
but
if
you're
writing,
for
example,
a
native,
a
mobile
app,
the
BMPs
core
is
not
available
because
it
is
a
JavaScript
library,
and
at
that
point
you
need
to
do
forests
or
whatever
why
problems
could
be
suitable
for
your
that
platform.
The
coverage
of
the
MPAA's
core
is
fair.
A
It
is
not
exposing
all
of
the
different
rest
ideas.
What
is
available
there,
but
it's
we're
already
exposing
the
typical
set
of
rest
api
and
it's
expanding
all
the
time
and
also
the
ETF
used
is
no
doubt
easy,
because
it
is
actually
super
easy
to
get
the
data
and
even
post
the
data
and
create
items
in
a
SharePoint
site,
and
we
can
I
show
that
one
in
in
practice,
during
the
demo,
as
well,
while
they're
connecting
with
one
out
on
this
one
I
think.
B
That
the
benefit
of
the
approach
is
that
you
get
intelligence
truth
when
you
work
with
rescue,
basically
type
strings
and
as
with
strings
you
can
have
typos
parameters
might
be
incorrect
and
the
only
way
for
you
to
actually
check
if
everything
works,
as
it's
supposed
to
is
to
do
it
on
runtime
or
write
some
really
complex
tasks
that
will
basically
try
to
mimic
the
whole
flow,
whereas
with
p.m.
PJs
core,
you
basically
work
with
fluent
API
that
has
cut
strip
types,
so
everything
will
be
everything
that
you
write
all
of
the
requests,
the
operations.
B
A
B
B
A
Technically
you
can
implement
server-side
the
implementation
side
of
it
as
well,
so
good
cool,
so
a
lot
of
talking
and
different
options.
But
let's
actually
have
a
look
on
this
in
practice.
So,
let's
jump
to
a
demo,
while
this
kind
of
walkthrough
or
a
few
of
our
existing
samples
which
are
available
in
the
bean,
the
PNP,
sorry
both
in
the
in
the
key
table
under
a
SharePoint
organization,
and
then
we
can
actually
then
we'll
come
back
on
the
slides
and
close
up
the
webcast.
B
All
right
so
now
that
you've
seen
or
heard
and
heard
actually
what
year
the
different
approaches
are
to
load
data
from
every
side.
How
about?
We
have
a
look
at
the
code,
how
these
approaches
look
in
practice.
So,
first
of
all,
we
have
a
web
part,
a
SharePoint
framework
web
part
that
uses
the
SharePoint
JSON
to
get
the
data
from
a
list.
B
B
Alright,
let's
stop
the
web
part
and
close
terminal
alright.
So
if
you've
worked
with
the
SharePoint
change,
eh
eh
tsamina
past
you
know
the
way
it
works.
First
of
all,
you
have
to
context
right
and
here
because
we
are
in
the
workbench,
we
don't
get
that
for
free,
so
we
have
to
create
it
ourselves
and
we
created
by
passing
in
the
URL
of
a
current
site.
B
Then
we
want
to
get
a
list
of
all
lists
in
this
site,
but
we
don't
want
to
get
for
every
list.
The
whole
list
we'd
be
because
we
only
show
a
title.
We
only
want
to
get
that
to
minimize
the
in
the
overhead
that
we
put
in
so
with
that
we
call
the
context
get
wet.
The
current
web
from
web
get
the
current
list,
and
then
we
do
a
trick
where
we
say
load.
The
collection
only
include
title,
and
this
syntax
is
specific
to
JavaScript
om.
B
You
won't
find
it
anywhere
else
right,
so
you
have
to
know
that
this
is
the
way
it
works
and
now
because
we
only
call
the
load,
the
load
itself
only
adds
an
operation
to
the
batch,
but
it
doesn't
really
execute
the
operation.
So,
in
order
for
us
to
actually
run
the
operation
and
get
data,
we
have
to
call
the
execute
query,
async
method
and
only
then
Jason
will
execute
the
call
the
rest
call
and
we'll
get
data
from
through
which
we
we
have
to
enumerate.
B
B
B
You
have
to
add
all
these
entries
and
they
have
to
be
exactly
added
that
way,
because
what
you
see
here
are
not
only
the
URLs
which,
by
the
way,
must
be
absolute
URLs
in
your
site.
Externals
do
not
work
with
relative
URLs,
because
I
relative
URL
would
be
relative,
comparing
to
the
past
where
the
source
code
is
located
and
not
relative
to
your
site.
So
that
would
not
work.
B
So
you
have
to
include
the
full
all
URL
and
then
you
have
to
have
the
name,
but
also
you
have
to
use
these
guys
dependencies
to
specify
the
order
in
which
frameworks
should
load
all
the
scripts,
because
if
you
load
them
incorrectly,
you
will
get
error,
because
these
scripts
do
depend
on
each
other
right.
So
they
might
have
a
reference
to
a
script.
That's
supposed
to
be
already
available,
and
if
it's
not,
you
will
have
error.
B
So
you
have
to
do
all
of
that,
and-
and
there
is
also
another
way
to
load
these
scripts
in
code
right
so
that
you
can
work
with
a
relative
URL,
but
you
still
have
to
get
through
all
the
hoops
in
loading
all
the
scripts
in
a
right
order
in
order
to
be
able
to
use
them
right,
and
there
are
also
typings
that
you
have
to
load
as
well,
so
that
you
can
get
5
script
types
right
and
you
can
find
them.
These
are
the
types
that
you
have
to.
B
B
We
just
saw
also
that
there
are
three
order
approaches
right
there,
zero
rest,
which
you
would
typically
use.
Let's
say
an
angular
there's
the
H
DSP
HTTP
client
that
you
get
in
SharePoint
frameworks
and
there
is
the
SP
p.m.
PDF
for
library.
So
how
about
we
have
a
look
and
add
that
intent
as
well
and
the
first
thing
here
it
ok
awesome.
We
have
another
sample
for
that.
So
let's
quickly
run
that
as
well
and.
A
B
We
will
actually
paste
all
of
the
code
in
video
so
that
you
will
be
able
to
type
it
all
right.
Let
me
remove
the
web
part
refresh
the
page,
there's
a
chance
of
the
web
or
we
reappear.
No,
it
doesn't
very
good,
and
now
we
have
samples
here
and
they
work
exactly
the
same
way.
So
if
I
add
angular
react,
SCP
EMP
they
work
exactly
the
same
way.
The
only
thing
that
is
not
the
same:
it's
actually
the
code.
So
let's
grab
the
one
in
angular.
B
Let's
quickly
set
the
list
the
name
of
our
list
test
and
then
in
that
we
can
create
new
items.
We
can
read
them.
We
can
read
all
items
you
can
change
them,
delete
them,
so,
basically,
for
every
operation
in
crud
so
create
read,
update,
delete.
We
have
an
operation
implemented
in
code
so
that
you
can
see
exactly
how
it
works,
how
it
works
in
angular
in
react
and
no
framework
at
all
and
then
with
SP
PM
pas.
So
now,
let's
have
a
look
in
code.
How
it
works,
there's
our
crop
sample.
B
Let's
stop
that
so
that
we
will
get
a
little
bit
more
screen
aside
here
and
as
first
of
all,
let's
have
a
look
at
the
angular
web
part
that
that
shows
how
you
work
with
raw
rest.
So
here
is
our
sir
is,
and
here
are
the
different
operations
that
we
have
so
first
of
all.
Well
in
angular,
when
you
work
with
rest
or
if
you
would
do
the
same
in
jQuery,
no
count
or
view
you
work
with
row
rest.
So
whenever
you
perform
a
let's
say,
let's
first
have
a
look
at
a
gift
operation.
B
So
that's
simple:
you
only
issue
a
web
call,
you
say
get
API,
URL
and
you're
done
and
and
in
in
response
you
actually
get
JSON
object
with
which
you
can
work.
If
you,
however,
want
to
create
an
item
or
issue
a
non
get
operation,
there
are
quite
a
few
steps
that
she
has
to
take
into
account.
So,
first
of
all,
when
you
create
an
item,
you
have
to
get
the
type
of
object
that
you
have
to
send
in
your
post
operation
and
that's
called
a
list
item
entity
type
name.
B
You
can
get
it
from
an
API,
but
that's
the
first
step
that
you
have
to
do
right.
So
does
the
one
call
here
then,
when
you
have
that
you
have
to
get
the
request
digest.
This
basically
is
a
security
measure
so
that
the
API
knows
that
that
you
are
allowed
to
issue
the
call,
because
you
perform
a
non
yet
operation,
yeah,
okay
and
then
the
next
step
is.
You
have
to
then
create
the
the
body
of
your
post
request.
B
So
here
you
can
see
that
we
pass
the
type
that
we
got
initially
here
and
then
we
we
say
title
of
our
new
item
that
we
want
to
create
in
the
list.
Then
we
issue
the
post
call
with
all
of
the
body
and
only
then
we
are
done
and
we
have
to
do
that
ourselves.
All
of
it.
We
don't
get
anything
for
free
all
right,
so
we
have
to
go
through
all
that
and
we
have
to
go
through
all
that
for
create
delete,
update
all
of
that
right
so
that
that
might
be
cumbersome.
B
But
the
good
thing
is:
if
you
build
apps,
let's
say
in
angular
iOS
no
J's:
it
works
exactly
the
same
across
all
of
them
because
in
none
of
them
you
something.
So
you
have
to
build
all
of
that
by
yourself
right.
It
might
not
be
efficient
at
first,
but
once
you
do
it
a
few
times
you
will
get
home
all
of
it
of
how
it
works.
B
Another
way
that
you
that
you
can
use
is,
for
example,
in
react
if
you
use
the
SP
h,
TDP
client,
that
you
get
with
the
web
part
and
that's
a
really
key
part,
because
if
you
look
at
the
API,
there
are
actually
two
of
them.
There
is
the
regular
HTTP
client,
but
there
is
also
the
SP
HTTP
client
and
there
are
some
nuances
difference
between
them
and
the
most
important
one
is
that
when
you
use
the
HTTP
client
that
does
not
send
cookies
that
you
have
currently
set.
B
So
if
you
would
try
to
use
that
bump
I
accident
I
would
try
to
call
the
SharePoint
rest
time.
Api,
every
single
call
would
be
403
unauthorized
forbidden.
Actually.
Why?
Because
the
cookie
that
you
currently
have
set
in
browser
would
not
be
sent
along
right,
so
every
single
cold
sale-
and
it
might
take
a
moment
for
you
to
actually
figure
out
why
right
so?
Actually
the
difference
is.
Whenever
you
want
to
call
shéi,
shéi,
shéi,
sharepoint
api,
you
always
have
to
use
the
SB
HTTP.
B
A
Then
should
be
fair
on
that
one.
The
whole
purpose
is
that
the
Essbase
is
it
a
client,
is
making
stuff
easier
for
you.
So
absolutely
you
don't
have
to
use
that,
but
if
you
wouldn't
be
using
that,
then
you
would
have
to
deal
with
the
cookies
and
everything
else
on
authentication.
What
on
top
of
our
so
absolutely.
B
Absolutely
absolutely,
and
with
that,
let's
say,
for
example,
let's
have
a
look
at
operations
like,
let's
start
with
read/write.
So
with
this
read
another
one,
we
just
issue
a
jet
jet
go.
That's
simple
right:
we
don't
need
to
do
mountain
pass
here,
but
then
for
create.
What
you
do
here
is
we
start
with
the
list
item
empty
cut
type
name,
so
we
still
have
to
do
that.
But
then,
as
you
can
see
here,
we
don't
need
to
get
the
request
I,
just
our
cells.
B
We
get
that
already
for
free
and
we
don't
don't
even
need
to
attach
that
to
headers,
because
all
of
that
is
already
being
done
by
the
client
that
we
use
all
right.
So
that's
actually
the
benefit
that
it
takes
away.
One
operation
that
otherwise
we
would
have
to
do
ourselves
and
then,
with
the
it
digest
another
thing
that
you
have
to
keep
in
mind
that
it
expires.
So
it's
not
enough
to
get
it
just
once
right,
because
it
expires
every
three
minutes
or
a
minute
right.
B
So
when
it
expires,
yes
actually
get
new
one,
so
you
either
have
to
get
new
one
every
single
time.
You
want
to
do
a
non
get
operation
or
you
would
get
it
once
and
then
keep
track
of
its
expiry
date
and
what
it
expired.
You
or
you'd
get
a
new
one
with
the
ESPE
HTTP
client.
You
don't
need
to
do
any
of
that,
because
you
get
all
of
that
for
free
right,
so
that's
another
benefit
there
and
then
finally,
we
have
the
SP
PM
PJs
library,
and
for
that-
and
that
is
just
very
easy.
B
So
here
let's
say
you
want
to
get
an
item
from
a
list,
so
you
say:
PM
p,
SP
wet
list,
because
we
want
to
get
an
item
from
a
list.
We
first
get
the
list
by
name
and
then
we
get
an
item
by
ID
and
from
dead
eyes,
and
we
only
want
to
have
title
and
ID
yet
done
only
this
line.
There
is
no
strings
for
dealing
strings
that
we
have
are
actually
the
name
of
the
fields
we
want
to
get,
but
other
than
that
it
just
fluent
API
and
let's
say
I
would
do
I.
B
B
We
get
this
for
for
free.
We
also
get
a
and
yet
a
digest
for
free
as
well,
and
we
also
do
not
need
to
create
the
whole
post
object.
We
only
pass
the
object,
a
really
short
short
part,
which
is
actually
the
body
of
the
item
that
we
want
to
create.
So
that's
really
simple.
Compare
this.
Let
me
open
that
for
you
size
side
by
side,
so
here
you
can
see
there
is
sugar,
sugar,
sugar
short
one
day
we
get
from
the
SPP
and
VKS.
B
Let
me
actually
close
the
pain,
and
here
let's
have
a
look
at
crud
that
you
would
have
to
authorize
yourself.
So
here
you
have
the
create
item
which
fits
exactly
on
the
screen
right
where
it's
dead.
These
only
takes
a
few
lines
of
code.
So
here
you
have
to
get
the
list
item
entity
type
name
you
have
to
get
or
actually
we
can
even
compare
it
to
angular.
So
imagine
that
you
would
just
use
raw
rest
to
make
it
really
fair.
Imagine
that
raw
rest
right.
B
So
here
you
have
the
get
list
item
entity
type
in
and
yes,
it
is
at
first
then
you
need
need
to
have
a
digest.
Then
you
have
to
have
the
body
with
the
type
in
it
as
well.
I
don't
and
then
only
then
you
actually
do
post
that
you
have
to
write
all
of
that
by
yourself
and
if
you
would
do
a
typo
here,
you
won't
see
it
in
code
because
it
is
string
right.
B
So
you
will
only
see
it
on
round
one,
whereas
here
you
work
with
objects,
so
you
see
everything
you
type
in
correct,
so
you
see
immediately.
So
that
is
a
big
benefit.
It
makes
it
really
easy
for
you
to
work
with
rest
in
a
way
because
this
API
works
internally
with
rest
right,
so
that
makes
it
easier
for
you
to
work
through
rest.
Eventually,
anything
I
missed
anything
else.
You
want
to
see
no.
A
I
think
that's
it
for
this
one
I
think
we
touch
the
key
points,
and
this
is
this
is
an
awesome
car.
Let's
say
comparison:
why
did
the
PM
BTS
core?
No
doubt
is
tough,
provide
value.
There
do
we
say
the
coverage
of
the
PM
details,
core
isn't
the
same
as
to
all
of
the
recipients,
but
for
basic
operations,
absolutely
worthwhile
to
have
a
closer
look
on
how
it's
working
and
the
intelligence
is
pretty
awesome
and
the
developer
time
checking
of
the
code
as
well,
but
I
think
just
should
be
enough
for
for
the
demo.
A
A
No
doubt
we
would
encourage,
is
to
have
a
look
on
this
baby
and
be
the
PHAs
core
library
if
it's
suitable
for
you
as
well,
and
if
it
feels
good
for
you
to
use,
because
that's
no
doubt
the
easiest
way
to
do
operations
like
you
saw
in
the
demo
as
well,
and
the
JavaScript
object
model
like
mentioned
when
we
went
through
the
slides.
It
is
already
it
was
a
release
back
in
2010
and
we're
not
really
investing
on
it.
Absolute
the
supported
option
in
the
in
the
in
the
SharePoint,
but
it's
not
something.
A
It's
not
really.
A
future
proof
as
such
first
API
is
absolutely
at
the
REST.
Api
is
the
future
of
SharePoint
swim-up
fbi's,
and
maybe
a
slight
note
on
that.
One
we're
not
going
to
actually
stop
really
and
releasing
a
dotnet
see
some
API
cedar,
but
the
rest
api
is
always
evolving
faster
and
then
the
SP
HTTP
request
or
the
sharepoint
framework
with
API
wrapper,
is
no
doubt
an
helpful
fellow
as
well.
In
adding
one
I'd
well
like
to
quickly
walk
through
the
different
options
of.
B
Course,
I
like
to
encourage
you
to
check
out
the
code
that
we
share
and
and
try
for
yourself
how
each
approach
work
and
based
on
that
choose
one
that
makes
that
that
is
actually
the
best
match
for
you
and,
as
we
said
Jason
is
it's
not
developed
anymore.
So
if
you
work
with
that
in
the
past,
I
would
encourage
you
even
more
to
have
a
look
at
the
RS
3
options
that
we've
shown
and
and
try
to
use
one
of
them
in
inset.